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
