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
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 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
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
