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. 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. > 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 opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
