Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> 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)?
>
> I would have expected that the kqemu and qemu interface to be private
> to the "qemu project" and as such the two parts need to be kept in
> sync. Basically if this was ON then it would be a "heads up for
> Cap-Eye Install users, use bfu to cross this putback".
>
> Thats not to say there isn't a generic issue here though.
>
Okay, I've done some more research.
1) The macros themselves that make use of _IOCPARM_MASK (_IOR, _IOW,
_IORW) are "private" to ON. That is, external code shouldn't be
directly using them. kqemu falls down here. I'm not sure we need to
worry about that.
2) I did find *one* potential issue in ON, which is that struct
iftun_req has a size of 600. All other ioctls defined in ON header
files use sizes that won't be truncated. The ioctls impacted are
SIOCGTUNPARAM and SIOCSTUNPARAM.
So my question here is how best to proceed. Options are:
1) Undo the change entirely.
2) Define some "compatibility" versions of the macros that are useful
only to these older ioctls, and make those ioctls use them.
3) Ignore the potential for breakage, on some belief (and I don't
advocate this) that nobody outside of ON is using those ioctls.
I think #2 above looks best. I'd like to have thoughts from other folks.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
