Jürgen Keil wrote:
> Hmm, in the past, nothing prevented me from passing
> ioctl parameter structures with a size > 255.
>
> qemu and it's kqemu kernel module are actually using such
> a big structure with the KQEMU_EXEC ioctl.
>
Ah, but the encoded size in the ioctl will be truncated. If you don't
*rely* on the encoded size, then there is no problem.
> 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...
>
> So, with the putback for 6711665 we have a small
> binary incompatibility.
>
Ouch. How much of a concern is this (for this particular case)?
-- Garrett
>
>> I've not seen any feedback on this, so I'm going to go ahead and file a
>> fast track. It looks fairly self-evident to me, but if someone has
>> concerns, it would be good to raise them soon. :-)
>>
>> -- Garrett D'Amore wrote:
>>
>>> Right now, drivers using sys/ioccom.h definitions for _IOR, _IORW, etc.
>>> are limited to passing structures that are at most 255 bytes. This
>>> seems a bit limiting, at least to me. In particular, other operating
>>> systems use a value that is much higher -- say 8191 maximum bytes.
>>> ...
>>>
>
>
> This message posted from opensolaris.org
> _______________________________________________
> opensolaris-code mailing list
> [email protected]
> http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
