* ioctl_list.2: complete overhaul needed @ 2014-11-09 15:50 Heinrich Schuchardt [not found] ` <545F8D2E.5030308-Mmb7MZpHnFY@public.gmane.org> 2020-04-14 11:07 ` Michael Kerrisk (man-pages) 0 siblings, 2 replies; 9+ messages in thread From: Heinrich Schuchardt @ 2014-11-09 15:50 UTC (permalink / raw) To: Michael Kerrisk (man-pages); +Cc: linux-man-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <545F8D2E.5030308-Mmb7MZpHnFY@public.gmane.org>]
* Re: ioctl_list.2: complete overhaul needed [not found] ` <545F8D2E.5030308-Mmb7MZpHnFY@public.gmane.org> @ 2014-11-11 7:14 ` Michael Kerrisk (man-pages) [not found] ` <5461B768.7040603-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 0 siblings, 1 reply; 9+ messages in thread From: Michael Kerrisk (man-pages) @ 2014-11-11 7:14 UTC (permalink / raw) To: Heinrich Schuchardt Cc: mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w, linux-man-u79uwXL29TY76Z2rM5mHXA 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <5461B768.7040603-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]
* Re: ioctl_list.2: complete overhaul needed [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> 0 siblings, 1 reply; 9+ messages in thread From: Mike Frysinger @ 2014-11-11 7:52 UTC (permalink / raw) To: Michael Kerrisk (man-pages) Cc: Heinrich Schuchardt, linux-man-u79uwXL29TY76Z2rM5mHXA [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <20141111075242.GB28132-eAEk4k+vi/E8xmjh+jFwDmGXanvQGlWp@public.gmane.org>]
* Re: ioctl_list.2: complete overhaul needed [not found] ` <20141111075242.GB28132-eAEk4k+vi/E8xmjh+jFwDmGXanvQGlWp@public.gmane.org> @ 2014-11-11 8:18 ` Michael Kerrisk (man-pages) 0 siblings, 0 replies; 9+ messages in thread From: Michael Kerrisk (man-pages) @ 2014-11-11 8:18 UTC (permalink / raw) To: Michael Kerrisk (man-pages), Heinrich Schuchardt, linux-man 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ioctl_list.2: complete overhaul needed 2014-11-09 15:50 ioctl_list.2: complete overhaul needed Heinrich Schuchardt [not found] ` <545F8D2E.5030308-Mmb7MZpHnFY@public.gmane.org> @ 2020-04-14 11:07 ` Michael Kerrisk (man-pages) 2020-04-14 15:37 ` Eugene Syromyatnikov 1 sibling, 1 reply; 9+ messages in thread From: Michael Kerrisk (man-pages) @ 2020-04-14 11:07 UTC (permalink / raw) To: Heinrich Schuchardt; +Cc: linux-man, Mike Christie 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/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ioctl_list.2: complete overhaul needed 2020-04-14 11:07 ` Michael Kerrisk (man-pages) @ 2020-04-14 15:37 ` Eugene Syromyatnikov 2020-04-14 16:21 ` Heinrich Schuchardt 0 siblings, 1 reply; 9+ messages in thread From: Eugene Syromyatnikov @ 2020-04-14 15:37 UTC (permalink / raw) To: Michael Kerrisk-manpages; +Cc: Heinrich Schuchardt, linux-man, Mike Christie 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} ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ioctl_list.2: complete overhaul needed 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) 0 siblings, 2 replies; 9+ messages in thread From: Heinrich Schuchardt @ 2020-04-14 16:21 UTC (permalink / raw) To: Eugene Syromyatnikov, Michael Kerrisk-manpages; +Cc: linux-man, Mike Christie 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/ > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: ioctl_list.2: complete overhaul needed 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) 1 sibling, 0 replies; 9+ messages in thread From: Michael Kerrisk (man-pages) @ 2020-04-15 6:48 UTC (permalink / raw) To: Heinrich Schuchardt, Eugene Syromyatnikov Cc: mtk.manpages, linux-man, Mike Christie 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/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Removal of the ioctl_list(2) manual page (was: Re: ioctl_list.2: complete overhaul needed) 2020-04-14 16:21 ` Heinrich Schuchardt 2020-04-15 6:48 ` Michael Kerrisk (man-pages) @ 2020-04-16 7:10 ` Michael Kerrisk (man-pages) 1 sibling, 0 replies; 9+ messages in thread From: Michael Kerrisk (man-pages) @ 2020-04-16 7:10 UTC (permalink / raw) To: Heinrich Schuchardt, Eugene Syromyatnikov Cc: mtk.manpages, linux-man, Mike Christie, lkml, Linux API [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/ ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-04-16 7:10 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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) [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)
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.