sowmini.varadhan at sun.com wrote:
> On (06/26/07 12:14), Garrett D'Amore wrote:
>
>>> With Clearview UV, we're introducing the notion of a link "class" (so far:
>>> aggregation, tunnel, vlan, vnic, and physical device), which is disjoint
>>> from the underlying media. There will be a "show" subcommand for each of
>>> these classes, along with "create-*" and "delete-*" subcommands when
>>> appropriate. In other words, it's pretty regular and thus we hope it will
>>> be fairly intuitive.
>>>
>
> so would it make sense for "dladm show-linkprop <foo>" to produce
> output similar to the following:
>
> LINK PROPERTY VALUE DEFAULT POSSIBLE
>
> <foo> zone ...
> <foo> mtu ...
>
> Ethernet properties:
>
> LINK DUPLEX CAPABLE ADV PEERADV
> <foo> half 10M 10M 10M
> <foo> full 10M,100M,1G 10M,100M,1G 10M,100M
>
> (assuming that <foo> was ethernet)
>
> i.e., the show-linkprop command recurses once by default to produce the
> show-<linkclass> command?
>
>
>
>>> WiFi is a bit of an "odd man out", in that we needed some way to
>>> conveniently show important WiFi information. I still have some regrets
>>> regarding "show-wifi", but on the other hand it is easier to grok than a
>>> sea of properties.
>>>
>
> If we extend the above proposal for wifi, we would have
>
> # dladm show-linkprop wpi0
> LINK PROPERTY VALUE DEFAULT POSSIBLE
> wpi0 channel 10 -- --
> wpi0 powermode ? off off,fast,max
> wpi0 radio ? on on,off
> wpi0 speed 54 --
> 1,2,5.5,6,9,11,12,18,
> 24,36,48,54
> wpi0 zone -- -- --
>
> WiFi properties:
>
> LINK STATUS ESSID SEC STRENGTH MODE
> SPEED
> wpi0 connected Radio Lsys wep very good g 54Mb
>
>
> the additional show-* command should only happen if a link is specified
> in the command line, i.e., doing "dladm show-linkprop" should not result
> in calls to show-<linktype>.
>
This just doesn't make sense to me.
A bunch of the properties above (powermode, radio, channel) are really
wifi-only properties.
I would really prefer to have two separate commands:
* show-linkprop which displays all properties in all their glory (and
frankly omits the "helpful" DEFAULT, POSSIBLE settings, because I think
it they are more likely to be confusing (what is more useful is an
indication of whether a property is read-only or not!) This is the
advanced interface, and can be used for access via scripts, etc.
* show-dev or somesuch, which displays the device details in a manner
that is most appropriate for the underlying media. (I don't care if we
call it show-dev, or something else). This is the normal "human
parseable" API.
I also still prefer friendly format commands for the most common "set"
operations. (Particularly those which involve a bunch of properties
getting set together, such as forcing a link speed/duplex.)
> the "sea of commands" issue will be dealt with by the "-p" argument
> (and there we would print the ethernet MII props exactly as defined
> in the ieee802.3(5) page, for any script that wishes to parse the output).
>
> Just a thought.
>
>
>> Yes, but if a single administrative command is easier than setting a
>> half-dozen or so properties, wouldn't you choose that?
>> Particularly if you
>> could demonstrate that that single administrative command met the needs of
>> the vast majority of users?
>>
>
> Well, the dladm repository would remember the setting.
>
That doesn't help admins figure out the initial setting. Having to
figure out the MII properties to configure a forced link speed/duplex is
probably a bit obtuse. I think we can do better.
> There's also other short-cuts like the shell alias, or wrapper scripts
> for this purpose.
>
Yes, but I think the point is that we want to make *dladm* easier to use
out of the box. Not require customers to craft their own shell scripts
because our interfaces are baroque.
-- Garrett
> --Sowmini
>
>
