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. -- Darren J Moffat _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
