Peter Memishian wrote:
> > So maybe the nice friendly presentation doesn't need to be here. Maybe
> > it doesn't need to be in the "default" output at all. (Whatever that
> > means.)
> >
> > AFAICT, the sites that tune these values *usually* have some harebrained
> > idea that turning off autonegotiation and forcing a fixed speed/duplex
> > setting is a good idea.
> >
> > MAYBE, we can provide a short cut for these users in the UI... e.g.
> > "force-link-speed-duplex" magic property or somesuch.
> >
> > 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?
>
> 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?
>
>
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.
I suppose this means assuming that all "private" tunables fall off the
beaten path, which is probably not a terrible assumption. It also sort
of assumes that dladm set-linkprop is by its very nature an "advanced"
operation.
For example, we could imagine that for WIFI you might imagine a property
called "ssid". Rather than setting this directly via set-linkprop, we
have connect-wifi and the NWAM GUI. One could easily imagine a similar
simplification for the link properties, such as "enable-jumbo" for jumbo
frames or somesuch. (Actually, the plethora of different jumbo frame
sizes that various NICs support is *another* annoyance. I think we
should just pick a standard Solaris value that is typical... say 9000
bytes or somesuch, and then abandon the attempts to support other less
common "jumbo sizes". The infinite tunability here is more likely to
cause problems for customers than to help them.)
-- Garrett
