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?