Peter Memishian wrote:
> > I'm not sure I understand the fear around creating a new subcommand,
> > that shows only ethernet specific information? (Btw, this could be
> > done for tun, aggr, or other link types as well. In fact we have it
> > already for aggr and wifi, with dladm show-aggr and dladm show-wifi.)
>
> With Clearview UV, we're introducing the notion of a link "class" (so far:
> aggregation, tunnel, vlan, vnic, and physical device), which is disjoint
> from the underlying media. There will be a "show" subcommand for each of
> these classes, along with "create-*" and "delete-*" subcommands when
> appropriate. In other words, it's pretty regular and thus we hope it will
> be fairly intuitive.
>
> WiFi is a bit of an "odd man out", in that we needed some way to
> conveniently show important WiFi information. I still have some regrets
> regarding "show-wifi", but on the other hand it is easier to grok than a
> sea of properties.
>
I think for a few of the ethernet tunables, this is true as well.
The number of properties provided with ethernet is quite large (half a
dozen or more properties corresponding to supported mode, peer's mode,
and what we have enabled! :-)
I think we can reasonably assume that few people will need to tune
these, and of those, far and away the most common tuning will be to
force one particular mode and duplex setting. Having to do this through
this "sea of properties" seems unwieldy. Which is why I suggested that
this common case be modeled with a particular subcommand.
The ability to *inquire* the current speed and duplex is certainly
useful. :-) (I guess dladm show-dev combined with dladm show-link gets
the most important information now, though I'd still like to show
whether the current state was the result of autonegotiation or
administratively forced.)
The only other ethernet tunable which seems "common" is the mtu. All
the others are probably so unlikely to need to be tuned that they should
really be hidden away under the dladm set-linkprop command.
> In general, I think we need to very conservative when creating new
> subcommands, since we risk creating an overwhelming administrative
> experience akin to the 50 ifconfig subcommands. One goal of *-linkprop
> was to reduce the proliferation of subcommands (and e.g., we've folded the
> originally-proposed *-autopush Clearview subcommands into a simple
> `autopush' link property). Of course, almost anything *could* be modeled
> as a property, so its applicability is ultimately a judgment call.
>
Yes, but if a single administrative command is easier than setting a
half-dozen or so properties, wouldn't you choose that? Particularly if
you could demonstrate that that single administrative command met the
needs of the vast majority of users?
(In the case of the autopush, which should rarely need to be
customer-accessible, I agree that a link prop is a better choice. :-)
Just as I would argue the same for interpacket-gap properties for
ethernet. :-)
-- Garrett
