[EMAIL PROTECTED] 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
_______________________________________________
driver-discuss mailing list
driver-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/driver-discuss
