1. 26
  1. 2

    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.

    1. 1

      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.

      1. 1

        For example, from sys/sys/ioccom.h:

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

        The underlying logic:

        #define _IOC(inout,group,num,len) \
                (inout | ((len & IOCPARM_MASK) << 16) | ((group) << 8) | (num))

        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.