Re: New tools proposal: ioctlname and ioctldecode

[christos%astron.com@localhost (Christos Zoulas)]

In article <2096.1585816582%jinx.noi.kre.to@localhost>,
Robert Elz  <kre%munnari.OZ.AU@localhost> wrote:
>    Date:        Thu, 2 Apr 2020 04:11:17 +0200
>    From:        Kamil Rytarowski <n54%gmx.com@localhost>
>    Message-ID:  <be3c1587-5a05-179c-7121-6b2153f9a556%gmx.com@localhost>
>
>  | This is partially enforceable. As once we generate catchall switch like:
>  |
>  | case FOO_OP:
>  | ...
>  | case BAR_OP:
>  | ...
>  |
>  | a compiler will report error whenever FOO_OP = BAR_OP.
>
>That makes it easy to detect, not enforce.   Once detected that way,
>what happens next?  Neither will (or can really) change as they both
>have existing applications compiled that use them - in the worse case
>the conflicts come from attempting to implement compat mode for someone
>else's binaries, and support their existing ioctl's (which we obviously
>cannot alter) - and do that for two different systems at once.
>
>This is the same reason we cannot fix the few duplicates that exist in
>our code - we want to retain backward binary compatibility, which means
>supporting ancient binaries that happen to use those ioctl values.
>
>Avoiding conflicts is (always has been) the aim - it allows drivers to
>detect attempts to use an ioctl intended for some different device, rather
>than believing it was intended for them, but there simply isn't, and can't
>really be, any way to enforce that.
>
>kre
>
>ps: don't forget all the sockioctl()s which also need decoding.   Perhaps
>even more than device ioctls.

We already have a lot of dups. See the mkioctls script.

christos