It turns out that for some code, having the IOCPARM_MASK encoding
correct is very useful.
1) OSS would like to have a centralized copyin/copyout.
2) truss and utilities can report structure sizes "correctly"
3) perl can use the encoding to ensure that a properly sized buffer is
allocated.
None of these apply to _IOC_NR(), which isn't in sys/ioccom.h at all.
Anyway, I sent out a flag day message about the issue.
-- Garrett
Joerg Schilling wrote:
> Alan Coopersmith <[EMAIL PROTECTED]> wrote:
>
>
>> Garrett D'Amore wrote:
>>
>>> 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.
>>>
>> Are they? I've been working to get our DRI/DRM (graphics direct
>> rendering, not media rights/restrictions) changes upstream - currently
>> the drm.h header exports the ioctl defintions as:
>>
>> #define _IOC_NR(nr) (((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)
>>
>
> In SunOS-4.x, these definitions were needed and SunOS-4.x indeed is unable
> to deal with ioctl parameters > 255 as copy in/out was donee by the kernel.
>
> With SunOS-5.x, the numbers in the IOCTL function number are only something
> like a "hint". Copy in/out is done by the driver and the driver knows the
> real
> sizes of the structures. Unless there is a clash, I see no need to extend
> _IOC_NRMASK.
>
> Jörg
>
>
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
