Darren Reed writes: > >that every competent project team must face. It's a non-trivial basic > >engineering decision, and not something that can just be waved away as > >something that somehow magically goes away because of "open source." > > > > I don't think it goes away because of "open source", if anything it > becomes more acute. With, Nemo, for example, we introduce a new way > for Solaris network interface drivers to be written that is not > available to 3rd party network interface driver development. > While in the past this might have been concealed, open source makes > it easy for 3rd party developers to see what the difference is.
I disagree, because I've seen exactly how this issue affects third parties in other areas on Solaris, and has affected them since long before there was an "Open Solaris." The lack of a stable way to plug into the file system interfaces has meant serious ongoing trouble for third parties that deliver their own file systems on Solaris. I think it has more to do with a lack of usable interfaces for certain important purposes than it does with being open or closed. If you feel that open source really does change the intensity or nature of the situation, then I (once again) urge you to take that up with the Tonic team. Addressing it project by project seems like a piecemeal approach to the problem, and unlikely to have lasting results. The Tonic folks are responsible for making sure that open development issues are handled properly -- inside and outside of Sun. > How do we encourage 3rd party developers to target Solaris if > we are using superior interfaces (for performance) than the ones > they are able to use? Is it ok to set double standards like this? > Or should we be forcing our own development to use the same set of > interfaces as external people can and create a level ground for > competition? I don't view it that way at all. It's not a double standard, and it's not an us-versus-them issue at all. It's a plain engineering issue. It's not a double standard, because all projects, both inside and outside of Sun, play by these rules. Those non-Sun parties are free to integrate into ON via the existing Open Solaris process, and thus use any Consolidation Private interfaces they want or need, just like any Sun project. Conversely, we (Sun) are *NOT* free to deliver Sun products via non-ON consolidations (whether bundled in Solaris or not!) that use ON's private interfaces. The restrictions apply to us as well. I simply do not buy the argument that we're drawing lines between Sun and non-Sun people. Quite the opposite. Both are in one community now. That part has changed. What has not changed are the engineering issues in putting together reliable software. The plain engineering issue here is that when I change some part of the software, I *need* to know exactly what might be affected so that I can fix them as well. That's where the interface taxonomy comes in. If that interface is Stable, I might not be able to change it at all, because there's no feasible way to find out who is using it. Those things are set in stone. If it's Consolidation Private, I know that all of the legitimate users are in one consolidation, and I can use grep/cscope to find and fix all of the consumers. If it's Project Private, my search is even shorter. It's not really a matter of being "fair." It's a matter of doing competent design, and not allowing software to just fall apart in the customer's hands. The fairness issue, if there is one at all, is in how project teams decide which things to make public, and when they do it, and how they consider the impact on their own and other's environments by doing so. This is the point where you can reasonably ask, "can you make this interface public so I can use it?" It's also the point where the project team can reasonably say, "no, we can't, because we expect to rototill it again, and we don't want to break you in the process." Asking them to be done some time before they're actually done does not seem quite fair to me, but perhaps it's something you could take up with the management of that project team. And this is also the point where ARC contracts come in. Those delivering software outside of ON (including, of course, non-Sun people) can still use those Nemo interfaces, provided that they establish a contract with the Nemo team. Contracts are just a fancy way of saying "the project team will put your name on a list and agree to let you know when they're changing something." > Using the word "forcing" is too strong for what I had in mind, but being > more encouraging of continued effort on interfaces to ensure that they go > from being *.Private to Stable. Although I recognise this is a bigger > problem than just at the ARC level and I do want to get more involved > and learn more about how the ARCs work. If that's it, then we're already there. We already do that. If you still need more, talk with your management, the PAC, and/or the Tonic team. > In general, yes, you are right. There's a wealth of information and > interfaces available in Solaris that make most things easy - except > for networking. When I look at the manual pages in section 9, there > has been very little there apart from STREAMS message manipulation > until gld was introduced. Talk with the owners of the interfaces you're concerned about. Seriously, that's what's needed here if you want that situation to change. -- James Carlson, KISS Network <[EMAIL PROTECTED]> 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 _______________________________________________ networking-discuss mailing list [email protected]
