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.
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
clear in the context of Brussels what the point of maintaining a second
persistent value is.
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. This is more like a capability in some respects,
except it represents the initial state of the tunable in the absence of
other influences (such as persistent data in a Brussels or SMF database.)
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. And, as indicated
above, I'm not sure that the notion of changing a hardware-supplied
"default" tunable value is meaningful.
Note that this has nothing to do with the idea of a "default_mtu" as the
link parameter versus the "mtu" value tuned in the IP stack. That's a
totally different meaning for "default". Maybe that is where some of the
confusion comes from?
I also don't think we have any kind of notion of "default" which says
something like "all ethernet links should default to 1500" (or even,
"all e1000g devices default to mtu of 9000"). I just don't see that
form of wildcarding with properties as being something we support right now.
-- Garrett
> --Sowmini
>
>
> _______________________________________________
> brussels-dev mailing list
> brussels-dev at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/brussels-dev
>
