sowmini.varadhan at sun.com wrote:
> [Note truncated recipient list]
>
> On (06/26/07 15:51), Garrett D'Amore wrote:
>
>>> I'm curious why you think having three properties (ala cap,
>>> advcap and lpadvcap) wouldn't be a reasonable tradeoff?
>>>
>
>
>> Because:
>>
>
>
> I think the point that meem is trying to make is that maybe we
> should not feel obliged to stick to the lettering in the ieee802.3(5)
> man page, but leave that as "legacy ndd support", while we seek
> a more concise, but still useful presentation format, with a new
> man page if needed.
>
If you don't call it "legacy ndd support", but instead call it "detailed
debugging properties", I'm more inclined to agree.
Basically, we need to have all the properties available. There will be
some (very!) small number of people who need the ability to change the
negotiation values. In fact, the QA group needs this feature for
testing that NICs function properly and negotiate properly. ;-)
I agree that some better presentation can be done in the UI for these
values. Most people won't care, for example, what the link partner
supports, or what the actual hardware supports (except, maybe, knowing
whether the device is a gigabit, 100mbit, or some other kind of
device!). They'll care more about:
* what is the current value (negotiated or not)
* forcing a set mode
If a "meta" property is used to allow forcing a mode, it should probably
validate the mode against the lower level cap_xxx properties to make
sure that the underlying device is physically capable of operating at
the requested mode.
>
>> a) that doesn't tell the whole story. (is autonegotiation enabled? that's
>> another boolean! and having it disabled is a distinct case from having it
>> enabled with only one mode advertised.)
>>
>> b) i guess having adv_cap be tunable via a comma delimited list would work,
>> but it is likely to be more confusing than just "please force this mode"
>> (which is what admins who diddle here really want)
>>
>> c) just setting a single forced mode is all (arbitrary unsubstantiated
>> statistic alert!) 99% of the customers who do diddle here need...
>>
>> Given that this is the state of affairs, lets make case "C" above as easy
>> as possible.
>>
>
>
> Raymond and I will go back and think about how to compress the information
> in ieee802.3 (if it can be done).. stay tuned.
>
Please *don't* go down the approach of performing a lossy compression.
At *some* place, all the values need to be accessible.
They just don't need to all be presented by default to a typical user.
> Meanwhile, it sounds like the "general" property list is not that long:
> it currently has mtu, zone, autopush. Is there anything else that we
> foresee adding in the future? Something related to security? Wake-on-lan
> related tunables?
>
Does "autopush" fit in there, even? (I don't know how this will be
used, so its a real question.)
Apart from the mtu, do we anticipate admins actually normally wanting to
access these values? (The mtu is kind of special.)
Other tunables will surely come about... but they may be media
specific. (E.g. 802.1x and linksec are only for 802 networks. wpa/wep
are only for 802.11.)
I'm sort of thinking that show-linkprop should be our ndd-like
replacement inteface, and that the couple of other properties (mtu,
maybe the zone) belong in the show-<linktype> output.
-- Garrett
> --Sowmini
>
>
