Why did ktrace decode this to VIDIOC_S_FMT when it actually wasn’t? This would probably have been a much shorter trip if ktrace wasn’t being actively misleading.
If you look at the kdump(1) source, there’s a step where it scans the header files and tries to build a mapping between the ioctl command value and the text name. The challenge is a command value isn’t really a way to uniquely describe the ioctl(2) call since it’s really the combo of device (as fd) and command.
This means it’s best effort to keep the command values globally unique using some macros like _IOWR, _IOW, etc. Sadly we have some collisions to fix. :-)
edit: I think I misinterpreted your question…I still believe there’s probably something going on in kdump(1), which is where the human translation occurs. Have to look.
/*
* Ioctl's have the command encoded in the lower word, and the size of
* any in or out parameters in the upper word. The high 3 bits of the
* upper word are used to encode the in/out status of the parameter.
*/
So the signed/unsigned interpretation can goof up the “inout” directional part, but leave the identifying group and num parts intact. Have to look at kdump(1) to see how this manages to still be recognized, though.
Why did ktrace decode this to
VIDIOC_S_FMTwhen it actually wasn’t? This would probably have been a much shorter trip if ktrace wasn’t being actively misleading.If you look at the
kdump(1)source, there’s a step where it scans the header files and tries to build a mapping between theioctlcommand value and the text name. The challenge is a command value isn’t really a way to uniquely describe theioctl(2)call since it’s really the combo of device (as fd) and command.This means it’s best effort to keep the command values globally unique using some macros like
_IOWR,_IOW, etc. Sadly we have some collisions to fix. :-)edit: I think I misinterpreted your question…I still believe there’s probably something going on in
kdump(1), which is where the human translation occurs. Have to look.For example, from
sys/sys/ioccom.h:The underlying logic:
So the signed/unsigned interpretation can goof up the “inout” directional part, but leave the identifying group and num parts intact. Have to look at
kdump(1)to see how this manages to still be recognized, though.