mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rob Landley <rob@landley.net>
To: musl@lists.openwall.com
Cc: Rich Felker <dalias@aerifal.cx>,
	musl@lists.openwall.com,
	"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>
Subject: Re: Re: Linux manpages (was Re: [musl] Request for volunteers)
Date: Tue, 09 Jul 2013 11:42:49 -0500	[thread overview]
Message-ID: <1373388169.27613.31@driftwood> (raw)
In-Reply-To: <51DB56CD.6050306@gmail.com> (from mtk.manpages@gmail.com on Mon Jul  8 19:18:21 2013)

On 07/08/2013 07:18:21 PM, Michael Kerrisk wrote:
> Rich,
> > I think it's an error to have anything glibc-specific in section 2  
> of
> > the manual, which should be documenting the kernel, not userspace.
> > What would be useful in the section 2 man pages is to document where
> 
> ("useful" to who? Few users care about the naked
> syscall behavior.)

We exist. :)

Speaking of which the data blob sent to sched_{get,set}affinity() is an  
array of longs, with each processor's bit living at:

   int x = 255 & (mask[cpu/sizeof(long)] >> (8*(cpu&(sizeof(long)-1))));

I know this because I implemented taskset against the raw system call,  
and read kernel code until I found the obscure corner where this is  
actually documented, namely:

   arch/powerpc/include/asm/bitops.h

(And yes, _only_ described in that architecture, not in any of the  
others. Go figure.)

(The toybox project is not a GNU program, and does not #define  
GNU_DAMMIT to access extra magic header bits. Where necessary, it  
provides its own header definitions.)

> > the syscall is insufficient to provide POSIX semantics, which are  
> left
> > to userspace to provide. Such section 2 pages could then have
> > corresponding section 3 pages that document the library behavior.
> 
> See  
> https://www.kernel.org/doc/man-pages/todo.html#migrate_to_kernel_source
> I think it would be a retrograde step to split syscall pages into
> Sections 2 and 3. Users want to get the documentation in one place.
> Note that the approach in man-pages (consolidating info on the syscall
> plus any libc additions in one page) is not unique to Linux. From some
> (offlist) discussions with the BSD man pages maintainers, it appears
> that at least some (all?) of the BSDs do the same.

Document what the syscall does, and then have wrapper behavior listed  
in the "deviant glibc-specific perversions" section?

Syscall wrappers in Section 2 make sense, it _is_ a syscall, and most  
wrappers should be NOPs. The objection is not documenting what the  
actual syscall does (when you can call it via syscall(), or get the raw  
behavior when using klibc).

Rob

  parent reply	other threads:[~2013-07-09 16:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-01 17:44 Request for volunteers Felix Janda
2013-07-02  1:08 ` Michael Kerrisk (man-pages)
2013-07-06 21:52   ` Linux manpages (was Re: [musl] Request for volunteers) Isaac
2013-07-06 22:12     ` Michael Kerrisk (man-pages)
2013-07-06 23:04       ` Justin Cormack
2013-07-07  0:03         ` Rich Felker
2013-07-09  0:18           ` Michael Kerrisk
2013-07-09  2:36             ` Kurt H Maier
2013-07-09  2:53             ` Rich Felker
2013-07-09  5:28               ` Michael Kerrisk (man-pages)
2013-07-10 19:39                 ` Rob Landley
2013-07-09 16:42             ` Rob Landley [this message]
2013-07-09 16:50               ` Rich Felker
2013-07-26 19:20   ` status of POSIX man pages? (was: " Isaac
2013-09-06 12:23     ` Re: status of POSIX man pages? John Spencer
2013-09-08  6:05       ` Michael Kerrisk (man-pages)
2013-09-09  4:44         ` John Spencer
2013-09-09  5:29           ` Anthony J. Bentley
2013-09-09  5:40             ` Daniel Cegiełka
2013-09-19  2:58               ` Rob Landley
2013-09-19  9:54                 ` John Spencer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1373388169.27613.31@driftwood \
    --to=rob@landley.net \
    --cc=dalias@aerifal.cx \
    --cc=mtk.manpages@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).