Peter Memishian wrote:
> > > An important point to note is that, since show-linkprop is
> > > intended to only be the complement of set-linkprop, it will only
> > > display the r/w properties (see (c) below for finding the read-only
> > > properties).
> > >
> >
> > I'm not entirely sure I agree with that last point. But I'm willing to
> > concede it, if there is some value perceived in displaying less than the
> > full set of properties here.
>
> I'm also a bit nervous about this, since whether a given property can be
> modified may depend on the given driver. However, if the goal is to
> ensure that status and statistics things don't end up dumped into the
> properties output, then I'm on-board. (FWIW, the last sentence was the
> guiding principle we used when deciding what was appropriate to model as
> a property for WiFi ).
>
>
See, that's where I think you and I have to agree to disagree.
The distinction between statistic and property seems a bit contrived to
me, and ultimately it is confusing to users. Even today, when driver
developers could just use kstats for state information, and ndd only for
tunables, we find statistics that are duplicated in ndd. Why? I
propose that it is because ultimately, one-stop-shopping is easier, and
it sucks to try to remember whether a given property is a statistic, or
a tunable.
What I'd prefer to see is all the properties (including statistics)
shown by the show-linkprop command (or it could be called get-linkprop
maybe?), along with two boolean attributes: is it a well-known property,
or private to the driver, and is it read/write or read only.
Conversely, I love that we have dladm show-wifi and the proposed dladm
show-ether which will show only the most relevant properties and
status. In this model, I believe that most folks would learn to use
just those, and only revert to dladm show-linkprop when they really,
really want to see the full output, or when they want to query the value
of a particular statistic/property.
-- Garrett
