All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk (man-pages)" <mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
To: Heinrich Schuchardt <xypron.glpk-Mmb7MZpHnFY@public.gmane.org>
Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
	linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Subject: Re: ioctl_list.2: complete overhaul needed
Date: Tue, 11 Nov 2014 08:14:48 +0100	[thread overview]
Message-ID: <5461B768.7040603@gmail.com> (raw)
In-Reply-To: <545F8D2E.5030308-Mmb7MZpHnFY@public.gmane.org>

Hello Heinrich,

On 11/09/2014 04:50 PM, Heinrich Schuchardt wrote:
> 
> Hello Michael,
> 
> the current ioctl_list.2 man-page descripton starts
> "This  is  Ioctl List 1.3.27, a list of ioctl calls in Linux/i386 kernel 
> 1.3.27."
> So the man-page represents the state of Sep 14th, 1995.
> It enumerates only 421 out of over 1200 calls.

Yep. There's no doubt that the man page is in a sorry state.
(But, I think a few of those other ioctls are documented in some 
section 4 and section 7 pages.)

> The list contains hex values of different constants. I just wonder for 
> which architecture (alpha, i386, mips, or sparc at that time). No 
> information is supplied.
> 
> Current values depend on the architecture, e.g.
> 
> On amd64
> 0x82307201      VFAT_IOCTL_READDIR_BOTH
> 0x82307202      VFAT_IOCTL_READDIR_SHORT
> 0x80047210      FAT_IOCTL_GET_ATTRIBUTES
> 0x40047211      FAT_IOCTL_SET_ATTRIBUTES
> 0x80047213      FAT_IOCTL_GET_VOLUME_ID
> 
> On mips
> 0x42187201      VFAT_IOCTL_READDIR_BOTH
> 0x42187202      VFAT_IOCTL_READDIR_SHORT
> 0x40047210      FAT_IOCTL_GET_ATTRIBUTES
> 0x80047211      FAT_IOCTL_SET_ATTRIBUTES
> 0x40047213      FAT_IOCTL_GET_VOLUME_ID
>
> Hence hex values should be removed.

It sounds like you are right that the hex values should be 
removed. But, how did you determine those different
hex values above? Grepping the sources, it's not
obvious that amd64 and mips should be different.
 
> I further suggest to remove all documentation of structure details.

Could you elaborate this point a little. Some examples, and
why you think they should be removed. I'm not disagreeing, just
looking to clarify what you mean.

> The following command can be used to create the raw data for a new list
> 
> grep -GHrn -B3 -A3 --regexp="\s_IO[R|W|RW]\?[_BAD]\?\s*(" \
> include/uapi | \
> sed ':a;N;$!ba;s/\\\s*\n[^-]*-[^-]*-/ /g' | \
> sort | \
> grep --regexp="\s_IO[R|W|RW]\?[BAD]\?\s*(" | grep -n ''

Thanks -- that's very helpful!

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

  parent reply	other threads:[~2014-11-11  7:14 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-09 15:50 ioctl_list.2: complete overhaul needed Heinrich Schuchardt
     [not found] ` <545F8D2E.5030308-Mmb7MZpHnFY@public.gmane.org>
2014-11-11  7:14   ` Michael Kerrisk (man-pages) [this message]
     [not found]     ` <5461B768.7040603-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2014-11-11  7:52       ` Mike Frysinger
     [not found]         ` <20141111075242.GB28132-eAEk4k+vi/E8xmjh+jFwDmGXanvQGlWp@public.gmane.org>
2014-11-11  8:18           ` Michael Kerrisk (man-pages)
2020-04-14 11:07 ` Michael Kerrisk (man-pages)
2020-04-14 15:37   ` Eugene Syromyatnikov
2020-04-14 16:21     ` Heinrich Schuchardt
2020-04-15  6:48       ` Michael Kerrisk (man-pages)
2020-04-16  7:10       ` Removal of the ioctl_list(2) manual page (was: Re: ioctl_list.2: complete overhaul needed) Michael Kerrisk (man-pages)

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=5461B768.7040603@gmail.com \
    --to=mtk.manpages-re5jqeeqqe8avxtiumwx3w@public.gmane.org \
    --cc=linux-man-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=xypron.glpk-Mmb7MZpHnFY@public.gmane.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.