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 actually impacts the OSS audio software, which supplies its own
overrides just for this reason.
It seems like it might be a good idea (and very reasonable) to change
the value of IOCPARM_MASK to 0x1fff, which as far as I can tell will not
impact any other software which is using the value properly. (The only
possible risk I can see, is that tools like truss(1M) might not report
sensible structure value sizes larger than 255 bytes, but then again,
they don't do that already.)
Thoughts? Any compelling reason not to change the value IOCPARM_MASK to
0x1fff?
-- Garrett
PS: Within ON, that mask appears only to be used in: ioccom.h, perl, and
truss. Of those, ioccom.h would not be impacted, Perl looks (at least
to my eyes) to be safe -- it uses this to check that enough space is
allocated for passing ioctl parameters, and truss would not be impacted
-- except that it could properly report structure sizes larger than 255
bytes (i.e. no negative impact.)
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
