James D. Carlson wrote:
> Jürgen Keil writes:
> > The putback for 6711665 did break kqemu for me,
> > because the kernel module was compiled on bits before
> > the 6711665 putback, and the qemu application that is
> > using the ioctl was compiled after the putback.
> > The old kernel module didn't understand the new ioctl
> > codes any more...
> Can you explain the incompatibility you found in more
> detail? Perhaps in the form of a complete bug report?
The KQEMU_EXEC ioctl was defined like this:
% grep KQEMU_EXEC kqemu.h
#define KQEMU_EXEC _IOWR('q', 1, struct kqemu_cpu_state)
Apparently we have sizeof(struct kqemu_cpu_state) == 584;
or 0x248 in hex.
The qemu application that I did compile today (on a machine
bfu'ed to post snv_92 bits) is using ioctl command code
0xc2487101.
The kernel module that I compiled last week was testing for
ioctl code 0xc0487101. That is, in the old kernel module the
structure's size of 0x248 was silently truncated to 8-bits
0x248 ==> 0x48.
Of cause the old kernel module didn't know about the change
in the ioctl code, and failed the "unknown" ioctl with EINVAL.
Since I have source code for both the application and the
kernel module, the fix was easy: just recompile both the
kernel module and application code on post snv_92
opensolaris bits.
> In particular, how did the kqemu private ioctl change after this
> integration?
0xc2487101 => 0xc2487101
> This CR changed only the IOCPARM_MASK value, and no
> other drivers we know of had to be changed as a result, so it sounds
> to me like kqemu had to be doing something _very_ strange for this to
> be true.
>
> How did kqemu have a dependency on IOCPARM_MASK?
By using the <sys/ioccom.h> file and the _IOWR macro.
This uses something like ((sizeof (t))&IOCPARM_MASK)<<16
This message posted from opensolaris.org
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
