Jürgen Keil writes:
> James D. Carlson wrote:
> > 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.
So the length value wasn't correct before, as it was truncated in the
ioctl generated. OK.
> Of cause the old kernel module didn't know about the change
> in the ioctl code, and failed the "unknown" ioctl with EINVAL.
Yep.
> > 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
I'd expected it was something stranger than just that.
Garrett: did you check for any ioctls that might have previously (and
silently) blown over the IOCPARM_MASK limit? Could you do so?
Something like this ought to do it:
extern int this_doesnt_exist;
( sizeof (t) > IOCPARM_MASK ? (uintptr_t)&this_doesnt_exist : 0 )
Anything that tries to use the macro with an illegal size will end up
failing to link because that symbol (intentionally) isn't defined
anywhere. (It could perhaps have a better name. No, I couldn't think
of a better way to do this other than tricking the optimizer into
doing our work for us. #if won't necessarily work on sizeof ...)
--
James Carlson, Solaris Networking <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
