Re: New tools proposal: ioctlname and ioctldecode

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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.