sowmini.varadhan at sun.com wrote:
> On (06/26/07 02:52), Peter Memishian wrote:
>
>> > For example, the output could show:
>> >
>> > LINK SPEED DUPLEX MODE
>> > bge0 1G full autonegotiated
>> > hme0 100M half forced
>> >
>> > Users who want the full control, as well as the full output, could
>> > access the properties directly.
>> >
>> > Thank God they finally required full-duplex and autonegotiation for 10G.
>> >
>> > Thoughts?
>>
>>
>
> Just catching up on this thread- it strikes me that the above discussion
> (of a possible show-linkcap) is very ethernet specific- I think a GUI
> would be a better way to take the MII info and package it in some
> aesthetic way, rather than burden dladm with another link-type
> specific show-* command.
>
> similarly, Garrett's suggestion:
>
>
>> What we really need is a simple UI for managing the "common" tunables (and
>> maybe exposing them as "properties" isn't the best way to handle this! see
>> for example the way we handle WIFI "properties" for SSID... they have their
>> own subcommands), and then an "advanced mode" that lets one access all of
>> the properties directly, as properties. For this advanced mode, I don't
>> think we have to really do a whole lot more than NDD already does (for
>> end-users anyway), although having consistent property names will be a big
>> help.
>>
>
> makes me a bit nervous: are we going to end up with ifconfig's
> too-much-syntax problem? It would be better for the CLI to be simple
> (if clumsy) and let a GUI deal with an eye-pleasing interface, and manage
> hierarchies that arise from link-types.
>
I'm not sure that this is a risk.
We do need at least one simple, easy to parse or use programmatically
API. (Basically a replacement for NDD.) The link-prop commands fill
that need.
But we also need a usable, more friendly CLI. dladm is currently
filling that niche with several other subcommands (dladm show-link,
dladm show-dev, dladm {show,create,modify, etc}-aggr. It also provides
it for wifi today... dladm show-wifi, dladm scan-wifi, etc.
It is not unreasonable to extend this to do some ethernet-specific
"common" support. In this case I think we're only talking about three
subcommands:
dladm set-jumbo-frames {on/off} (See my earlier comments as to why
this needs to be a boolean value instead of an MTU size...)
dladm set-ethernet-mode {off/10h/10f/100h/100f/1000f/1000h}
dladm show-ethernet
This shows something like the show results I already proposed.
(One could even argue that the set-forced-mode shouldn't support forcing
1000f or 1000h... I think nobody forces speeds faster than 100Mbps these
days... at least they *shouldn't*.)
>
>> Would the properties still end up in the show-linkprop output? If so,
>> even well-behaved admins are still subjected to a mountain of properties
>> that they shouldn't even be using, which seems bad. Or are you proposing
>> some way to hide these properties? (I'm nervous about that as well.) If
>> we're sure this stuff will be off the beaten path, maybe we could reduce
>> the number of properties to just `cap', `advcap', and `lpadvcap' (or
>> somesuch) with a commas-separated list of values?
>>
>
> I'd initially felt that we should just print the bare-basics (like speed,
> duplex, autoneg), but both Raymond and Garrett pointed out to me that
> reducing the properties will just cause admins to regress to ndd usage.
> We could, though, have a "show-linkprop" vs a "show-linkprop -v" - the
> former would print the bare-basics, e.g., just the r/w props, (using the
> same adv* names as ieee802.3(5)), and the latter could print all the
> local/peer props in their gory glory.
>
I'm not sure I like that. I think the {show,set}-linkprop commands
themselves are a bit unwieldy for the uninitiated (as is ndd, btw).
Frankly, I'd prefer to provide friendlier usage for the commonly
adjusted tunables.
-- Garrett
