On (06/26/07 09:37), Garrett D'Amore wrote: >> 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? >> > > I guess that would work for me.
The devil is in the details, though. There are some "common" properties like mtu, which apply to multiple link types. So should the show-linkprop section be subdivided into multiple tables? What does UV do to the output? > But then will you do this also for things > like dladm show-aggr, dladm show-wifi, etc. If we go this route, then yes. --Sowmini
