> > 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 _______________________________________________ networking-discuss mailing list networking-discuss@opensolaris.org
