On (03/05/08 12:05), Garrett D'Amore wrote:
> sowmini.varadhan at sun.com wrote:
>> On (03/05/08 14:25), Peter Memishian wrote:
>>
>>> This all seems reasonable for what's proposed, but I wonder how it might
>>> be extended to handle an additional case that's come up in another thread.
>>> In particular, ndd currently allows one to effectively change the default
>>> value,
>>>
>>
>> Not sure I follow- could you provide an example? At least for datalink
>> drivers, afaik, ndd allows one to set or get values (typically the MII
>> parameters), and the "default" here is intended to be the value that
>> the driver would come up with when it attaches.
>>
>
> I hate that we continue to try to talk about how ndd does things today.
> Only because ndd is totally 100% busted as far as any kind of sane
> administration goes.
Meem specifically mentioned "ndd currently allows.. " so I was trying
to understand what specfically he was referring to.
> I think the point that I hear Peter making is that one can imagine
> changing the "default" value for a property.
>
> Thinking about this somewhat further, I have my doubts about the utility
> of a writable "default". As I see it, Brussels properties are now
> persistent. Why would an administrator change a "default" independently
> of changing the lasting persistent ("non-default") value? Its just not
Agreed.
> Note that in the context of *link* parameters, I believe that the
> "default" that comes from hardware is still meaningful. E.g. a hardware
> device that supports a "default" MTU of 1500, versus one that supports
> 9000 by default.
Correct. another example is the choices made for certain drivers
to turn on/off some speed-duplex values by default, based on the
type of underlying hardware.
> Given this, I still think I'd nuke DLIOCSETPROP with DLD_DEFAULT. A
> userland entity that wants to change the settings back to hardware
> default can just query and set in two operations.
This is fine with me, except that it's no longer atomic. I realize
that this is not a critical operation, so atomicity/single-system-call
are not big factors.
> And, as indicated
> above, I'm not sure that the notion of changing a hardware-supplied
> "default" tunable value is meaningful.
Agreed. It would be helpful to look at the example meem was thinking
about, so that we understand where he is coming from.
--Sowmini
