[changing subject line, and shrinking To list, to make this thread
easier to track]
On (06/26/07 21:15), Raymond LI wrote:
> Sowmini.Varadhan at Sun.COM wrote:
>>
>>> 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.
>>
>>
> This seems to be better than we introduces a completely new dladm
> subcommand. But a problem is what we should put in "-v" and what not.
> Dividing by "r/w" could be a solution, but I am afraid it will not satisfy
Just thinking aloud: another possibility is to have the full-display
in the -p output (parseable) so that it can be grep-ed. For the
"default" (i.e., no -p) show-linkprop output, we can print something
eye-pleasing, like Meem's suggestion (just provided as an example for
the purpose of discussion- there could be more/less fields in the final
output):
LINK DUPLEX CAPABLE ADV PEERADV
bge0 half 10M,100M,1G 10M,100M,1G 10M,100M
bge0 full 10M,100M,1G 10M,100M,1G 10M,100M
As we've already discussed in
http://mail.opensolaris.org/pipermail/brussels-dev/2007-June/000089.html
dladm already will have to subdivide public props based on link type
(so that it doesn't wander off into printing meaningless "N/A" values
of MII props for tunnels). So if we have to dmux on link type, why
don't we just tailor the show-linkprop output to capture relevant
information concisely for that link type?
--Sowmini
