[brussels-dev] Brussels: framework commitment materials

[James Carlson]

Sowmini.Varadhan at Sun.COM writes:
> > Remaining comments:
> > 
> >   - How are adv_*_cap Volatile?  What will change here?  (Does this
> >     actually mean Obsolete or something else?)
> 
> We chose the default option of making all Brussels interfaces Volatile
> until we got feedback on how user-friendly they actually were. 

I didn't know that was a "default."

Let me suggest an alternative.  Since Nevada hasn't released and
likely isn't going to release for some time, and since that's where
you're headed, I would recommend providing the bulk of these as
"Committed" interfaces, and making only a tiny minority of
questionable ones "Uncommitted."

You can still change them in incompatible ways any time you like so
long as the bits haven't been baked into a release.  The stability
levels refer to releases (major/minor/micro), and not to mere builds
or evaluation copies.

> In the case of the adv*cap options, the name of the parameter itself
> is somewhat clumsy, being chosen only because of its existing usage
> in ndd. The objective is that if we find that users 
> prefer other syntax, we could mark this Obsolete in future.

You wouldn't need to do that if it's not baked into a release that
way.

It sounds like you want to do some experimenting.  That's fine, but I
think that you should treat the interfaces "as if" someone actually
wanted to use them when assigning stability levels.  In that light,
"Volatile" is close to useless -- I can't actually use a program that
breaks command line arguments in a patch.

If you're sure that you'll run up to Nevada release being unsure about
the arguments, then make them Uncommitted.  You won't be able to break
them in a patch, but you won't have much of a support tail in the next
Minor release.

> >   - Loopback ioctls?
> 
> not sure I follow the question. Were you asking what steps would
> be taken to address the loopback ioctls issue raised at inception? 

Yes.

> We looked further into this issue, and found that SunVTS ioctls are not
> really "properties" that control the behavior of the interface, like
> other examples considered, but are part of loopback testing interfaces
> that are documented in netlb.h as "may be supported".
> 
> We've filed an RFE: 
>   6613193 loopback ioctls should be implemented as Brussels properties.
> to track this (currently under brussels:software/driver but will 
> be converted to solaris with putback)

OK; that's what I wanted to know.

> >   - Will use of ndd for drivers eventually go away?  Is that part of
> >     the plan or will we carry compatibility forever?
> 
> yes! Absolutely! this will be covered by the ndd compatibility 
> component of Brussels.  See Section 5.2 of 
>  http://cr.opensolaris.org/~sowmini/commitment.materials/brussels.pdf

Which is it?  Going away or staying forever?

I think the ndd administrative interfaces on drivers are a wart, and
it'd be nice at some point to nudge users away from them (when there's
a better alternative, such as dladm) at first, and then to _force_
them away by breaking ndd.

I don't see an obsolescence plan here.

-- 
James Carlson, Solaris Networking              <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677