Sowmini.Varadhan at Sun.COM wrote:
> On (03/06/08 23:18), Joost Mulders wrote:
>
>>> I remain unconvinced that the folks who are using it today or other
>>> things would need to continue to do so given the option of a dladm
>>> based
>>> equivalent.
>>>
>>>
>> I would like to add a big YES to the statement above!
>>
>> I don't understand why we put effort in maintaining compatibilty with
>> a mistake we made in the past. Or is just to punish ourselves for
>> making the mistake?
>>
>
> The idea is to clean up the existing ndd code in drivers
> to deal with these ioctls, while allowing scripts (and C code
> out there) that already has calls to ndd (or the underlying
> ioctl itself) embedded in them.
>
> After this is putback, drivers that have nd_param_t related
> swill today will be free of such code, and the ndd callers
> will not even notice
>
This is all good. But some swill will necessarily remain in the
framework itself. I would dearly love to eradicate ndd for link layer
tunables altogether. Continuing to support every bizzaro tunable (or
mispelled common tunable) in perpetuity seems like a high cost to pay.
FWIW, I don't think the ndd ioctls have *ever* been published
externally. The internal consumers I know of are either in ON, or can
(and should) be changed -- SunVTS comes to mind. (And in the SunVTS
case, I think it only uses those MII tunables I already talked about --
it doesn't use any driver specific tunables via NDD, at least the last
time I looked at the various network related SunVTS tests.)
Put another way, except for specific contracts or known cases (SunVTS),
there ought not be any consumers of ndd ioctls.
Use of the ndd binary in scripts is another matter entirely, but even
that type of use has historically been quite limited, and I doubt you'll
find many, if any, scripts that access it for other than MII or MTU.
-- Garrett
