mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Jesse Barnes <jbarnes@virtuousgeek.org>
To: "Michael Kerrisk" <mtk-manpages@gmx.net>
Cc: linux-kernel@vger.kernel.org, michael.kerrisk@gmx.net,
	Andries.Brouwer@cwi.nl
Subject: Re: man-pages-2.08 is released
Date: Thu, 13 Oct 2005 10:46:44 -0700	[thread overview]
Message-ID: <200510131046.44520.jbarnes@virtuousgeek.org> (raw)
In-Reply-To: <20785.1129193533@www73.gmx.net>

On Thursday, October 13, 2005 1:52 am, Michael Kerrisk wrote:
> Recently, I was just wondering the same thing.  However, there
> are complexities to consider.  C libraries (okay, glibc is the
> main one I concern myself with) sometimes add some functionality
> in the wrapper function for a particular system call.  This also
> needs to be documented in the Secion 2 page.

True.  But there are other libcs available (e.g. klibc, dietlibc) too.  
I'd think that if the pages were bundled with the kernel, they should 
describe exactly what the kernel does, while pages bundled with a libc 
would describe any enhancements (or breakages) that the particular libc 
includes.  But then what to do about duplicates?  Or should the raw 
kernel interfaces have their own section, while libc interfaces remain 
in section 2?  Or should the libc versions typically replace the kernel 
versions on running systems?  Or 'patch' the existing kernel pages 
somehow?  So many questions... ;)

> Nevertheless, I think the idea of binding the kernel sources and
> Sections 2 and 4 of the manual pages a bit more tightly bears
> some consideration.  In the ideal world, when a change is made to
> the kernel, the patch could include adjustments to the man
> pages (if relevant) -- then the changes could follow the patch
> through the -mm tree and then into Linus's tree.

That was my though too; it's certainly easier to ask people to update 
manual pages in Documentation/ or man/ when they do a kernel patch than 
to ask them to download a separate package and make the changes (since 
they'll probably never get around to doing the latter :).

> > OTOH, they comprise a fairly large package, so adding them to the
> > kernel tarball would increase its size a lot.
>
> I'd guess that the uncompressed source of the relevant pages
> would be around 3 MB.

Ok, that's not too bad.  Having full, up-to-date man pages would be worth 
the extra few megs to me at least.

> > The man pages are great;
>
> Thanks.  But the greatest part of credit must go to Andries,
> the maintainer for nearly 10 years.  I'm shortly coming up to my
> first anniversary...

Many thanks to both of you then!

Jesse

      reply	other threads:[~2005-10-13 17:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <434D5224.9754.10AC691@localhost>
2005-10-12 16:26 ` Michael Kerrisk
2005-10-12 17:10   ` Jesse Barnes
2005-10-13  8:52     ` Michael Kerrisk
2005-10-13 17:46       ` Jesse Barnes [this message]

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=200510131046.44520.jbarnes@virtuousgeek.org \
    --to=jbarnes@virtuousgeek.org \
    --cc=Andries.Brouwer@cwi.nl \
    --cc=linux-kernel@vger.kernel.org \
    --cc=michael.kerrisk@gmx.net \
    --cc=mtk-manpages@gmx.net \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®