Gidday,
I just released man-pages-2.57.
This release is now available for download at:
http://www.kernel.org/pub/linux/docs/manpages
or ftp://ftp.kernel.org/pub/linux/docs/manpages
and soon at:
ftp://ftp.win.tue.nl/pub/linux-local/manpages
Various things remain to be fixed in man-pages. A few of the outstanding
FIXME points from section 2 are listed below. Any assistance with these
points would be most welcome.
Cheers,
Michael
(man-pages maintenance is supported by Google, as a Google engineer 20%
project.)
==========
./man2/ioperm.2
FIXME is the following ("Only the first 0x3ff I/O ports can be
specified in this manner") still true? Looking at changes in
include/asm-i386/processor.h between 2.4 and 2.6 suggests
that the limit is different in 2.6.
==========
./man2/mprotect.2
FIXME
Document PROT_GROWSUP and PROT_GROWSDOWN
==========
./man2/nfsservctl.2
FIXME The description of nfsservctl() on this page
is woefully thin.
==========
./man2/shmop.2
FIXME A good explanation of the rationale for the existence
of SHMLBA would be useful here
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance? Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages/
read the HOWTOHELP file and grep the source files for 'FIXME'.
Michael Kerrisk <[email protected]> wrote:
> ./man2/ioperm.2
> FIXME is the following ("Only the first 0x3ff I/O ports can be
> specified in this manner") still true? Looking at changes in
> include/asm-i386/processor.h between 2.4 and 2.6 suggests
> that the limit is different in 2.6.
You now have the full 64Kb port bitmap (8 KB).
BTW1: linux/arch/i386/kernel/ioport.c still states having 8K of bitmaps to
be excessive (and implicitely and now wrongly as not being done). Since
there should only be few processes requiring iopl, the 8K should not be
excessive. We need a native speaker to change this text, at least not me
right now.
CC Linus, because he admitted fiddeling with this file. (No MAINTAINER found)
BTW2: My (possibly outdated) iopl manpage states that you'll need to be root
change the iopl, but you only need CAP_SYS_RAWIO in order to increase the
iopl.
--
Have you ever noticed that the Klingons are all speaking unix?
"Grep ls awk chmod." "Mknod ksh tar imap."
"Wall fsck yacc!" (that last is obviously a curse of some sort)
-- Gandalf Parker
> Michael Kerrisk <[email protected]> wrote:
>
> > ./man2/ioperm.2
> > FIXME is the following ("Only the first 0x3ff I/O ports can be
> > specified in this manner") still true? Looking at changes in
> > include/asm-i386/processor.h between 2.4 and 2.6 suggests
> > that the limit is different in 2.6.
>
> You now have the full 64Kb port bitmap (8 KB).
> BTW1: linux/arch/i386/kernel/ioport.c still states having 8K of
> bitmaps to
> be excessive (and implicitely and now wrongly as not being done). Since
> there should only be few processes requiring iopl, the 8K should not be
> excessive. We need a native speaker to change this text, at least not me
> right now.
If someone can come up with a technical description of what
should should go in the man page, I'm happy to fix the English.
> CC Linus, because he admitted fiddeling with this file. (No MAINTAINER
> found)
>
>
> BTW2: My (possibly outdated) iopl manpage states that you'll need to be
> root
> change the iopl, but you only need CAP_SYS_RAWIO in order to increase the
> iopl.
The current page includes this text under ERRORS
EPERM The calling process has insufficient privilege to
call iopl(); the CAP_SYS_RAWIO capability is
required.
Cheers,
Michael
--
Michael Kerrisk
maintainer of Linux man pages Sections 2, 3, 4, 5, and 7
Want to help with man page maintenance?
Grab the latest tarball at
http://www.kernel.org/pub/linux/docs/manpages ,
read the HOWTOHELP file and grep the source
files for 'FIXME'.
Bodo Eggert wrote:
>
> BTW1: linux/arch/i386/kernel/ioport.c still states having 8K of bitmaps to
> be excessive (and implicitely and now wrongly as not being done). Since
> there should only be few processes requiring iopl, the 8K should not be
> excessive. We need a native speaker to change this text, at least not me
> right now.
>
That text almost certainly dates back to when every process had a bitmap.
Unfortunately, in a case of utter design braindamage, you can't have the
I/O bitmap be more than 2^16 bytes away from the base of the TSS, so
fixing that took a long time.
-hpa