Re: New tools proposal: ioctlname and ioctldecode

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> $ ioctlname 2148554498
>>> WSKBDIO_COMPLEXBELL
>> Where would you get the mapping between the ioctl value and the
>> name?  [...]
> Everything is already done in kdump and reused in other tools like
> ktruss.

So, the big switch() method.

>> What about collisions, two ioctls having the same numeric value?
> There are some collisions, but not that many of them.  In these cases
> we try to pick the more interesting device.

For kdump, that makes some sense.  For this tool, I think it would make
the most sense to report them all.  (Arguably, kdump should too...)

Of course, that would mean changing things at least slightly from the
current kdump approach.  I'm not sure that would necessarily be a bad
thing, especially if we could somehow (major handwave here) tell which
ioctls go together, in which case kdump could do heuristics along the
lines of "this fd accepted FOO_IOC_A, so we're going to decode this one
as FOO_IOC_B rather than BAR_IOC_C".

I suppose that's the hazard of catchall interfaces like ioctl(): they
are difficult to make usefully discoverable.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B