[brussels-dev] dladm show-linkprop enhancements

[Peter Memishian]

 > > My original thinking (when coming up with show-linkprop for WiFi) was that
 > > we could add additional (optional) fields for whatever information we
 > > wanted.  For instance, we could have a DESC field that gives a short
 > > description of the property, or whatever.  The most commonly useful fields
 > > should be shown by default, and the rest should be available via "-o all".
 > > If there's general consensus that the convenience of "-v" justifies having
 > > it as an alias for "-o all", that seems fine to me.
 > 
 > I think that a better option may be to follow the "svcs -x" path,
 > and have a "dladm -xp <propname>". Alternatively, we could do
 > "dladm help <propname>" (following zoneadm), but I'm biased
 > toward the  -x method myself.

I think the "-x" way would be an odd fit for dladm given that all of its
existing subcommands are <verb>-<noun> and "-x" is an option letter.
Separately, I'm also a little skittish about smearing information about a
given property across distinct subcommands -- which "help" would do.

 > note that the above was just tentative output, and nothing written in 
 > stone..

Understood.

 > I think that, in subsequent discussions, we agreed to change the above
 > to match the MII names in ieee802.3(5)

But link_speed isn't listed in ieee802.3(5) -- so does this mean we'll use
"speed"?  More generally, I'm not convinced that reusing those names is
the right choice (Do we really want to have a "link_up" property?  Or do
we really need to have the output of show-linkprop to be knee-deep in
obscure link negotiation options like "lp_cap_1000hdx"?)

 > >    * Does a writeable link_status make sense?  And does it really have
 > >      a default?
 > 
 > This is a read-only property. I suppose the default should be "--" 
 > (i.e, undefined).

Yeah, that would make sense to me.

-- 
meem