mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Michael Kerrisk <mtk.manpages@gmail.com>
To: Rich Felker <dalias@aerifal.cx>
Cc: 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 02:18:21 +0200	[thread overview]
Message-ID: <51DB56CD.6050306@gmail.com> (raw)
In-Reply-To: <20130707000324.GU29800@brightrain.aerifal.cx>

Rich,

On 07/07/13 02:03, Rich Felker wrote:
> On Sun, Jul 07, 2013 at 12:04:04AM +0100, Justin Cormack wrote:
>>>> On a slightly related note, would you be interested in patches for the
>>>> Linux manpages briefly documenting places where musl differs from glibc
>>>> (in the NOTES section, along the same lines as the notes about
>> libc4/libc5)?
>>>
>>> Historically, man-pages has primarily documented glibc + syscalls, but
>>> there's nothing firm about that. It's more been about limited time
>>> resources and the fact that glibc is the most widely used libc. I'd
>>> have no objection to musl-specific notes in the man-pages. Perhaps a
>>> patch to libc(7) would be a good place to start.
> 
> I'm not sure how much effort would be involved. My ideal outcome would
> be for the man pages to evolve to document what applications can
> _portably_ expect from the interfaces, 

This is what the man pages endeavor to do. (I consider cases where 
non-portable behavior is not clearly indicated to be bugs.)

> with appropriate notes on
> caveats where certain libc versions or kernel versions give you
> less-than-conforming behavior, and where nonstandard extensions are
> available. 

That's more or less what the pages do, with the proviso that "certain
libc versions" currently means just glibc, and in a few odd cases, 
ancient Linux libc.

> However my feeling is that this would be a very big project
> and I'm not sure if Michael would want to go in that direction. I do
> think it would greatly improve the quality of Linux software
> development, though.
> 
>> The man(2) section is rather glibc specific and makes the syscall details
>> rather subsidiary. I will try to send some patches if these would be
>> welcome.
> 
> 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.)

> 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. 

Cheers,

Michael



  reply	other threads:[~2013-07-09  0:18 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 [this message]
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
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=51DB56CD.6050306@gmail.com \
    --to=mtk.manpages@gmail.com \
    --cc=dalias@aerifal.cx \
    --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).