Peter Memishian wrote:
> > > I'm still confused; why wouldn't it just record just the delta they've
> > > requested with += or -=?
> >
> > I thought you were saying:
> >
> > > If the admin has e.g. a SPEED-DUPLEX value of 100g-f,10m-h
> > > and they want to change the 10m-h value to 10m-f then they would need to
> > > enter 100g-f,10m-f, or first do -=10m-h followed by += of 10m-f.
> >
> > and I was addressing the first part of that sentence. So it would not
> > be possible to modify the existing set without a series of -= and +=
> > commands, and then "show-linkprop -p en-mii" would have to compute
> > the union of all such commands so far to figure out what to print.
>
> I see what you're getting at now, and agree it would add complexity
> to resolve.
>
> > My suggestion, otoh, would involve just one command that, to me,
> > is more intuitive, and doesn't involve keeping track of all the +/-
> > operations so far:
> > dladm set-linkprop -p en-mii=no-10m-h,10m-f ...
>
> Personally, I find that syntax really alien, and I'm not sure how it
> expands to the general case (cpus=no-23,12)?
>
> > I'm not too crazy about the -= and += syntax. So far we have had
> > a simple -p <name>=<value> interface, and now we are proposing that
> > a subset of commands that may take the -/+ adjustment as a sort of
> > "modify-linkprop". It adds a complexity, that as Garrett points out,
> > seems like overkill for this case.
>
> If it was just for this case, I'd agree. However, link properties are a
> general mechanism and the more we can put into the framework the less that
> gets dumped onto everyone else (including the administrator). But given
> their limited use at this point, I don't feel too strongly about it.
>
Solaris has a classic problem where code is over-engineered to support
hypothetical cases that never get used. (I can cite numerous examples
where I've encountered this.) This would be another such case, I
think. Lets not worry about solving a problem we don't actually have today.
If someone on the list can give me a concrete example of a link property
that would best be dealt with in this fashion, then I'm happy to
recant. But for now, putting a bunch of energy into solving this
doesn't seem like effort well spent.
Are there any ndd tunables that have historically used list syntax? The
only time I've seen list syntaxes used with driver.conf tunables for NIC
drivers is to provide global properties where the list elements each
represent the setting for a different NIC instance number as a
workaround to the horribly obtuse way of identifying PCI instances in
driver.conf. (Thankfully, we don't have *that* problem with dladm!)
To repeat: KISS.
- Garrett
