Re: New tools proposal: ioctlname and ioctldecode

[Kamil Rytarowski <n54%gmx.com@localhost>]

On 02.04.2020 03:33, Mouse wrote:
>>>> $ 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.
>

Yes.

We should maintain a contract that all new ioctl operations are system
wide unique.

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

This would be ideal... however it's not that simple and I would
recommend to go with the path of removing the conflicts entirely for the
general benefit.

For the time being we just live with conflicts and ignore a subset of
operations.

From a quick look there are conflicts e.g. due to chio(1) a SCSI charger
added in NetBSD 1.3 for and.com. Are there still any users?