ioctl_list.2: complete overhaul needed

ioctl_list.2: complete overhaul needed

[Heinrich Schuchardt]

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.

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.

I further suggest to remove all documentation of structure details.

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

Best regards

Heinrich Schuchardt
--
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

Re: ioctl_list.2: complete overhaul needed

[Michael Kerrisk (man-pages)]

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

Re: ioctl_list.2: complete overhaul needed

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 2342 bytes --]

On 11 Nov 2014 08:14, Michael Kerrisk (man-pages) wrote:
> On 11/09/2014 04:50 PM, Heinrich Schuchardt wrote:
> > 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.

ioctl's can integrate the type size right ?  so wouldn't be surprised if it 
changed across arches.

fwiw, strace carries a script to try and do all this magic automatically:
http://sourceforge.net/p/strace/code/ci/master/tree/linux/ioctlent.sh
of course it misses out on ioctls that aren't exported in headers and are 
internal to specific drivers.  i.e. it's not perfect at all, but that's because 
ioctls are a goddamn mess :).

i agree though that the man page should drop hex values as they aren't useful.  
if you're using a "standard" ioctl, you should get it from the relevant header 
file.  if you're using a "non-standard" ioctl, then you get the pieces.

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

i think for the common/standard ioctls, it's useful to have manpages that delve 
down into the details.  but for the fringe ones, it's a waste of time for the 
vast majority of people.

maybe one way to determine whether it's worth documenting, see if strace has a 
decoder for it :).
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: ioctl_list.2: complete overhaul needed

[Michael Kerrisk (man-pages)]

Hi Mike,

On Tue, Nov 11, 2014 at 8:52 AM, Mike Frysinger <vapier-aBrp7R+bbdUdnm+yROfE0A@public.gmane.org> wrote:
> On 11 Nov 2014 08:14, Michael Kerrisk (man-pages) wrote:
>> On 11/09/2014 04:50 PM, Heinrich Schuchardt wrote:
>> > 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.
>
> ioctl's can integrate the type size right ?  so wouldn't be surprised if it
> changed across arches.

Yes. I'd actually noticed that detail,and should have said so. I
suppose what I really meant was: is that the only source of the
difference in the constants?

> fwiw, strace carries a script to try and do all this magic automatically:
> http://sourceforge.net/p/strace/code/ci/master/tree/linux/ioctlent.sh
> of course it misses out on ioctls that aren't exported in headers and are
> internal to specific drivers.  i.e. it's not perfect at all, but that's because
> ioctls are a goddamn mess :).

Thanks for that pointer.

> i agree though that the man page should drop hex values as they aren't useful.
> if you're using a "standard" ioctl, you should get it from the relevant header
> file.  if you're using a "non-standard" ioctl, then you get the pieces.

Agreed.

>> > 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.
>
> i think for the common/standard ioctls, it's useful to have manpages that delve
> down into the details.  but for the fringe ones, it's a waste of time for the
> vast majority of people.
>
> maybe one way to determine whether it's worth documenting, see if strace has a
> decoder for it :).

Sounds like a reasonable idea to me.

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

Re: ioctl_list.2: complete overhaul needed

[Michael Kerrisk (man-pages)]

Hello Heinrich,

On Sun, 9 Nov 2014 at 16:52, Heinrich Schuchardt <xypron.glpk@gmx.de> 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.
>
> 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.


As you suggest, I've removed the hex values from the lists.

Thanks,

Michael


> I further suggest to remove all documentation of structure details.
>
> 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 ''
>
> Best regards
>
> Heinrich Schuchardt



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Re: ioctl_list.2: complete overhaul needed

[Eugene Syromyatnikov]

On Tue, Apr 14, 2020 at 5:18 PM Michael Kerrisk (man-pages)
<mtk.manpages@gmail.com> wrote:
>
> Hello Heinrich,
>
> On Sun, 9 Nov 2014 at 16:52, Heinrich Schuchardt <xypron.glpk@gmx.de> 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.
> >
> > 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.
>
>
> As you suggest, I've removed the hex values from the lists.

Those can be replaced with the _IO* macro definitions. Meanwhile,  the
list is somewhat far from complete; strace has some approximation that
can be uses a basis of a more complete and reliable list
(linux/{32,64}/ioctls_inc*.h and linux/*/ioctls_arch*.h), but I'm not
sure if it is worth adding to the man page (moreover, entries are
constantly being added and changed there; yes, breaking the kernel ABI
in the process sometimes).

> Thanks,
>
> Michael
>
>
> > I further suggest to remove all documentation of structure details.
> >
> > 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 ''
> >
> > Best regards
> >
> > Heinrich Schuchardt
>
>
>
> --
> Michael Kerrisk
> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
> Linux/UNIX System Programming Training: http://man7.org/training/



-- 
Eugene Syromyatnikov
mailto:evgsyr@gmail.com
xmpp:esyr@jabber.{ru|org}

Re: ioctl_list.2: complete overhaul needed

[Heinrich Schuchardt]

On 2020-04-14 17:37, Eugene Syromyatnikov wrote:
> On Tue, Apr 14, 2020 at 5:18 PM Michael Kerrisk (man-pages)
> <mtk.manpages@gmail.com> wrote:
>>
>> Hello Heinrich,
>>
>> On Sun, 9 Nov 2014 at 16:52, Heinrich Schuchardt <xypron.glpk@gmx.de> 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.
>>>
>>> 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.
>>
>>
>> As you suggest, I've removed the hex values from the lists.
>
> Those can be replaced with the _IO* macro definitions. Meanwhile,  the
> list is somewhat far from complete; strace has some approximation that
> can be uses a basis of a more complete and reliable list
> (linux/{32,64}/ioctls_inc*.h and linux/*/ioctls_arch*.h), but I'm not
> sure if it is worth adding to the man page (moreover, entries are
> constantly being added and changed there; yes, breaking the kernel ABI
> in the process sometimes).

Man-pages like netdevices.7 or ioctl_fat.2 are what is needed to help a
user who does not want to read through the kernel code.

If ioctl_list.2 has not been reasonably maintained since Linux 1.3.27
and hence is not a reliable source of information, shouldn't it be dropped?

Best regards

Heinrich

>
>> Thanks,
>>
>> Michael
>>
>>
>>> I further suggest to remove all documentation of structure details.
>>>
>>> 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 ''
>>>
>>> Best regards
>>>
>>> Heinrich Schuchardt
>>
>>
>>
>> --
>> Michael Kerrisk
>> Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
>> Linux/UNIX System Programming Training: http://man7.org/training/
>
>
>

Re: ioctl_list.2: complete overhaul needed

[Michael Kerrisk (man-pages)]

Hello Heinrich,

On 4/14/20 6:21 PM, Heinrich Schuchardt wrote:
> On 2020-04-14 17:37, Eugene Syromyatnikov wrote:
>> On Tue, Apr 14, 2020 at 5:18 PM Michael Kerrisk (man-pages)
>> <mtk.manpages@gmail.com> wrote:
>>>
>>> Hello Heinrich,
>>>
>>> On Sun, 9 Nov 2014 at 16:52, Heinrich Schuchardt <xypron.glpk@gmx.de> 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.
>>>>
>>>> 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.
>>>
>>>
>>> As you suggest, I've removed the hex values from the lists.
>>
>> Those can be replaced with the _IO* macro definitions. Meanwhile,  the
>> list is somewhat far from complete; strace has some approximation that
>> can be uses a basis of a more complete and reliable list
>> (linux/{32,64}/ioctls_inc*.h and linux/*/ioctls_arch*.h), but I'm not
>> sure if it is worth adding to the man page (moreover, entries are
>> constantly being added and changed there; yes, breaking the kernel ABI
>> in the process sometimes).
> 
> Man-pages like netdevices.7 or ioctl_fat.2 are what is needed to help a
> user who does not want to read through the kernel code.

Yes, I agree.

> If ioctl_list.2 has not been reasonably maintained since Linux 1.3.27
> and hence is not a reliable source of information,

I must confess I've never loved that page. and in the 24+ years since 
it was released, it's seen very little useful change to the content.
(You of course are well qualified to know that, since the biggest 
changes have come from you, and as we know they've not been anything
big.)

> shouldn't it be dropped?

I'm inclined to do so. Let's see if anyone else comments.

Cheers,

Michael



-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

Removal of the ioctl_list(2) manual page (was: Re: ioctl_list.2: complete overhaul needed)

[Michael Kerrisk (man-pages)]

[CC widened]

Hello Heinrich, Eugene,

On 4/14/20 6:21 PM, Heinrich Schuchardt wrote:
> On 2020-04-14 17:37, Eugene Syromyatnikov wrote:
>> On Tue, Apr 14, 2020 at 5:18 PM Michael Kerrisk (man-pages)
>> <mtk.manpages@gmail.com> wrote:
>>>
>>> Hello Heinrich,
>>>
>>> On Sun, 9 Nov 2014 at 16:52, Heinrich Schuchardt <xypron.glpk@gmx.de> wrote:

[...]

>>> As you suggest, I've removed the hex values from the lists.
>>
>> Those can be replaced with the _IO* macro definitions. Meanwhile,  the
>> list is somewhat far from complete; strace has some approximation that
>> can be uses a basis of a more complete and reliable list
>> (linux/{32,64}/ioctls_inc*.h and linux/*/ioctls_arch*.h), but I'm not
>> sure if it is worth adding to the man page (moreover, entries are
>> constantly being added and changed there; yes, breaking the kernel ABI
>> in the process sometimes).
> 
> Man-pages like netdevices.7 or ioctl_fat.2 are what is needed to help a
> user who does not want to read through the kernel code.
> 
> If ioctl_list.2 has not been reasonably maintained since Linux 1.3.27
> and hence is not a reliable source of information, shouldn't it be dropped?

As already noted, I'm inclined to agree that yes, this page probably
should be removed. What really is needed is pages such as ioctl_fat(2),
ioctl_userfaultfd(2), and ioctl_ns(2) that give useful details
to user-space programmers.

Just FYI, I've queued a change that removes the ioctl_list(2) page
in a private branch. By the time of the next release, I'll merge
that branch, unless someone has (good) objections.

There is one piece of ioctl_list(2) that is perhaps worth preserving:
the "ioctl structure" subsection. As part of these changes, I've
migrated that text to ioctl(2).

Cheers,

Michael

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/