Garrett D'Amore wrote:
> Darren Reed wrote:
>> Garrett D'Amore wrote:
>>
>>
>>> The IOCPARM_MASK removal was covered by PSARC case 2008/343. I'm
>>> thinking that MAXIOCBSZ is not a documented API, isn't used
>>> *anywhere* outside of the files I'm removing it from here (according
>>> to Google at least) -- apart from automatically generated Perl and
>>> Python files (generated from the header files), so I think I can
>>> probably get away without an ARC case for it. If anyone else on the
>>> recipient list feels different, let me know -- I can file an
>>> auto-approval case pretty trivially. (Mostly I didn't file the case
>>> just to avoid the 1 week timeout that such normally incurs,
>>> particularly since this seems pretty obvious at this point.)
>>>
>>>
>>>
>>
>> I think a fast track would be worthwhile, especially since you're
>> increasing the structure size allowed for ioctls which really does
>> mean that you're changing an interface. Auto-approved seems
>> to be appropriate?
>>
>
> Actually, I'm changing the size *allowed*. I'm changing the fact that
> the attached data will arrive as a single contiguous mblk, rather than
> broken across several smaller linked mblks.
Oops, that should say I'm "not" changing the size allowed. The
"interface" impact for device drivers is that they get a bigger M_DATA
now, rather than a chain of smaller M_DATAs. AFAICT, there is no real
public spec for how the data will be broken up.
I've not proposed to change the spec for drivers so that they can know
that it will all be in one M_DATA, but it may be worth doing that. I'll
file a case.
-- Garrett
>
> That said if you still believe a self-review case should be filed,
> then I'll do it.
>
> -- Garrett
>> Darren
>>
>> _______________________________________________
>> networking-discuss mailing list
>> [EMAIL PROTECTED]
>>
>
_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
