Joachim Worringen writes: > James Carlson wrote: > > Lacking the same semantics means that applications are left in an > > uncertain state. They may work, if they're lucky, and don't rely in > > any way on the unimplemented parts. They may also fail. And there's > > no simple way to know which applications are in which class. It's > > just happenstance. > > You are right, it's not 100% compatible, but close enough for most > applications. It's necessary to qualify specific applications, and > that's what we are doing. The target is to accellerate specific > applications, not to provide a 100% compliant replacement for TCP/IP > sockets.
I guess we'll have to leave it at that. > While talking about semantic compliance: Is there a publicly usable > socket test suite? We are writing test cases as we need them, but surely > don't cover "everything". I don't think the socket tests we use are public yet. http://opensolaris.org/os/community/testing/selftest/ A lot of the testing in that area is done with conformance test suites (such as from The Open Group), which means that you'd probably have to buy your own copy. > > (And that's not even mentioning the higher-level problems, such as > > having a data path that completely ignores configured IP filters, > > IPsec policy, QoS, and TX labeling.) > > These features are typically not needed within, say, a database cluster. > See above. It's hard to predict. Yes, I agree that there may be constrained environments where none of those things matter. Historically, though, what I've found is that it's not really possible to rely on _nobody_ ever having a need for _any_ such features. In other words, features that endure are ones that are flexible, and incompatible with other features isn't flexible. > > I don't think I understand that answer ... your question was about > > getting notification when an interface changes so that you can get the > > updated address / mask / flags on that interface. That's exactly what > > a routing socket will do. > > I just wanted to say "Thanks for the information, but we will not have > to use it right away, so expect me to come back with problems on this > part within a few months." ;-) Ah, ok. > >>> See neti and the existing IP Filter code ... but you'd likely want to > > An ARC contract isn't a financial or legal instrument; it's a > > technical tool that allows you to specify which undocumented > > interfaces you need to have unchanged for your code to continue > > working, and outline a plan for communicating and coordinating changes > > that are required. > > O.k., thanks for this advice. But what do you mean by "integrating into > the consolidation"? How would this change the status of an interface > being undocumented/volatile? It doesn't change the status; it changes how the code is managed. Many of the interfaces you'd want to use here are classed as "Consolidation Private." That means that projects integrating into the same consolidation (read, roughly: repository) can share these interfaces without restriction, and those changing the interfaces must make sure they coordinate with (or simply update) all dependent projects within the consolidation. Another (equivalent) way to look at it is that for these interfaces, the ARC defers to the consolidation to manage itself. It's a somewhat abstract boundary that maps into real-world bits: if you're changing some undocumented interface inside the ON consolidation, then you need to use cscope or find+grep or similar to make sure that you've updated all the references. You don't have to go fishing in other gates or through google searches to find other users, because, by definition, there are no _legitimate_ other users. An ARC contract allows for controlled and documented exceptions to those cases. It allows us to say "we aren't documenting this, and you can't see the dependencies in cscope, but we won't change it without coordinating with <fill in here>". It's not at all a perfect mechanism (having real documented interfaces is much better), but it's certainly better than documenting things that aren't yet ready for prime time. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> 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 _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
