James Carlson wrote:
> 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.
>
Yikes! I hadn't considered that there could be cases where lengths were
truncated.
>
>> 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?
>
I hadn't even considered this as a possibility -- I should have. :-(
> 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 ...)
>
I'll look around, and see what I can find.
-- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
