>>> $ 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 mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B