On (06/26/07 09:32), Garrett D'Amore wrote:
>> makes me a bit nervous: are we going to end up with ifconfig's
>> too-much-syntax problem? It would be better for the CLI to be simple
>> (if clumsy) and let a GUI deal with an eye-pleasing interface, and manage
>> hierarchies that arise from link-types.
>>
>
>
> I'm not sure that this is a risk.
>
> We do need at least one simple, easy to parse or use programmatically API.
> (Basically a replacement for NDD.) The link-prop commands fill that need.
>
> But we also need a usable, more friendly CLI. dladm is currently filling
> that niche with several other subcommands (dladm show-link, dladm show-dev,
> dladm {show,create,modify, etc}-aggr. It also provides it for wifi
> today... dladm show-wifi, dladm scan-wifi, etc.
>
> It is not unreasonable to extend this to do some ethernet-specific "common"
> support. In this case I think we're only talking about three subcommands:
>
> dladm set-jumbo-frames {on/off} (See my earlier comments as to why this
> needs to be a boolean value instead of an MTU size...)
>
> dladm set-ethernet-mode {off/10h/10f/100h/100f/1000f/1000h}
>
> dladm show-ethernet
>
> This shows something like the show results I already proposed.
There's a danger of feeping creaturism here.. we've already departed
from the minimalism expressed in dladm-wifi.pdf (see PSARC 2006/406
materials), but now the "set" action is taking more sub-actions
(why not have set-tunnel-hop-limit? what about set-wifi-essid?)
Another aspect is that we are requiring multiple levels of a show-*
command to extract useful information: show-linkprop vs show-<linktype>.
Granted, wifi has already gone this route, but it would be better
if we could avoid doing two lookups (and having to figure out the
linktype to do the second)
--Sowmini