Alan Coopersmith wrote:
> Garrett D'Amore wrote:
>   
>> The fix for 6711665 I'm not sure about.  One approach is to provide a 
>> compatibility macro (e.g.  #define IOCCOMPATSZ(x)  (sizeof (x) & 0xff)) 
>> and use it to define the known bad ioctls.  The problem is that this 
>> fixes the ioctls that are defined in ON, it doesn't help ioctls using 
>> these macros and defined elsewhere.  (Note that nobody should be using 
>> these macros!  They aren't part of any public API, and the header 
>> explicitly states that only sizes up to 255 bytes can be encoded.  I 
>> didn't expect anyone to violate those comments, which is what caught me 
>> off guard.)
>>     
>
> http://docs.sun.com/app/docs/doc/805-3024/6j2sumi4j?l=en&a=view#conv-41
> suggests they were public interface in SunOS 4.x and remain for
> compatibility.
>
> Unfortunately, a search of the ARC case archives shows much newer
> ioctls being defined using them, and I don't see a mention of
> public or private in the PSARC 1997/243 case that added _IOWRN to
> the set.
>
>   

This has got to be *ancient* legacy.  SunOS 4.x kernel source 
compatibility hacks were abandoned long ago.

I'm not worried about breaking 3rd party drivers ported from 4.x. :-)

    -- Garrett

_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to