mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rob Landley <rob@landley.net>
To: mtk.manpages@gmail.com
Cc: Rich Felker <dalias@aerifal.cx>, musl@lists.openwall.com
Subject: Re: Re: Linux manpages (was Re: [musl] Request for volunteers)
Date: Wed, 10 Jul 2013 14:39:34 -0500	[thread overview]
Message-ID: <1373485174.27613.41@driftwood> (raw)
In-Reply-To: <CAKgNAkgZt3sLoUMZc+2Fgn=HXBoB2acvasQD1=g19aknCjcf6w@mail.gmail.com> (from mtk.manpages@gmail.com on Tue Jul  9 00:28:17 2013)

On 07/09/2013 12:28:17 AM, Michael Kerrisk (man-pages) wrote:
> >> > 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.

I note that I'm nominally the kernel Documentation maintainer. If you'd  
like a Documentation/syscall directory handed over to you in  
MAINTAINERS, I can do that. (Or Documentation/DocBook/syscall, up to  
you...)

(I don't do nearly enough with it due to lack of time, and because  
every patch series in the world has a documentation bit I get cc'd on  
and How am _I_ supposed to judge the correct locking requirements for a  
Heterodyne Death Ray so half the time I just go "You need a comma in  
'Fools I shall destroy you all!'" and then ack it. Still eats up the  
time I have to devote to that topic, most weeks.)

At some point I'd like to completely reorganize that directory so (for  
example) all the architecture directories are under "arch". But this  
involves me setting up a git tree somewhere I can upload to and send  
pull requests about, and that's just icky enough to stay well below the  
surface of my todo list...

> > Yes, that's understandable. I somewhat question why we even still  
> have
> > a "section 2" in the manual, though...
> 
> Well then, you'll be amused to hear that the discussion with the BSD
> maintainers was about whether FreeBSD (and others) should simply merge
> Sections 2 and 3. I can see arguments in favor of it, but they're not
> (to my mind) compelling. See one piece from the thread below.

A system call is a different thing than a library call, even in libc.  
The fact glibc gets them confused is a problem with glibc.

In theory there is a "clean upstream" system call set in posix, and a  
"clean upstream" libc call set in c99 and/or posix. (In practice  
there's noting like subscribing to the austin group mailing list to  
rapidly erode your faith in the upcoming Posix standard. The sausage is  
made of people! And they're _INSANE_.)

Rob

  reply	other threads:[~2013-07-10 19:39 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 [this message]
2013-07-09 16:42             ` Rob Landley
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=1373485174.27613.41@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).