Peter Memishian wrote:
> > In earlier conversations, I was indicating that dladm needed (or would
> > need at some point) a way to enumerate "private" properties (quite apart
> > from ndd), so I tried to convince Sowmini to keep the APIs general.
> >
> > I don't think we should be exposing *any* feature via ndd that we don't
> > expose via dladm as well... in fact, I *would* like ndd to be a strict
> > subset of functionality available with dladm. (The smaller the subset,
> > the better, IMO.)
>
> But in this case ndd can be a strict subset without requiring dladm to
> have identical tunables. There are already better ways (e.g., the
> flowctrl [agh, I wish there were more vowels in that] link property) to
> accomplish the same end-result as these ndd legacy tunables, so I'd rather
> we didn't saddle the dladm show-linkprop output with them forever. In
> other words, I don't want show-linkprop to become a dump.
>
I understand *that* motivation. And frankly, the significant question I
ask here is, if we have a property that does what is required (e.g.
flowctrl), then *WHY* are we going to have even the remotest attempt to
support some "alternate" properties that accomplish the same thing.
This is like the variants of spelling errors or different - vs. _ word
breaks. Its ridiculous that we should be burning any time whatsoever on
those properties. If there is some weird spelling/punctuation that is
"quasi-standard" and scattered around in scripts, then it should be
supported (translated) internally by the framework, without asking
drivers to export a redundant property. If it isn't general enough to
be useful in the framework, then I *strongly* suspect that there is no
compelling reason why any hardware instance would need it.
On the other hand, the properties that are interesting are
hardware-specific tunables (e.g. some TX FIFO threshold tunable). And
those should be accessible by dladm. (Notably, I'm not sure they need
to be exposed via ndd. I still think we should be doing everything
possible to minimize the amount of stuff we expose or support via ndd,
and strongly encouraging developers and users to steer away from it.)
-- Garrett
