Peter Memishian writes:
>
> > That's a very good point.
> >
> > If we had to change the name to promote something from public to private,
> > in addition to all the user-surprises this would create,
> > the upgrade procedure would have to do the task of purging the old name
> > from the dladm repository and inserting the new one.
>
> The whole idea of private properties is that they are unstable across
> upgrades. The model you're currently proposing forces us to make a
> guarantee we can't keep: that we can transparently handle converting that
> driver-private property to a public one (including preserving the
> semantics).
The idea of promotion from private to higher seems somewhat dubious to
me.
If the property being established is in fact something that's common
-- either defined by the underlying hardware ("transmit power") or
some defacto or de jure standards -- then we shouldn't be creating any
private properties for it. Doing so would be a mistake for the same
reason that having each driver randomly and independently defining
driver.conf variables was a mistake. It ends up with chaos.
If they're to be respected at all, private properties have to be weird
and local. Anything else deserves a higher commitment and a more
thorough review.
Thus, I don't think it makes sense to worry much about promotion or
the disruption it would cause. It _does_ make sense, though, to make
sure that users can be aware that they're touching bits that might rot
over time. Naming (as in the link_* scheme) could be part of that.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
