Garrett D'Amore writes: > > - People who stumble into using it through no fault of their own, > > and end up hurt by incompatible changes we may make before > > stabilizing. > > > > - People who deliberately go out of their way to find the > > undocumented stuff we've got. > > > > You're making an assumption that these two sets are distinct. I'm not > sure they are. I think the latter can lead to the former. > > Put another way, I'm afraid some FOSS developers will find out where we > squirreled it away, and hard code it into configure scripts, or even > into binaries. (Much of the FOSS software we wind up dealing with comes > from places where developers have never even heard of ABI compatibility, > much less care about it.)
We can't _prevent_ people from finding things they're not supposed to find. We don't disable 'nm', we don't hobble dtrace, and you can find+grep over /usr/include to find all sorts of nasties. The original issue I raised was about making sure that we didn't use a well-known common name for something that wasn't ready to be used that way. The suggestion that someone might find our renamed device node and then hack his software to follow suit is perhaps a risk, but it's in the class of risks that I'm arguing we should not try to avoid: developers do all sorts of stupid things, from hijacking devops vectors to camping out on undocumented syscalls. > So having a name readily available (too easily, in other words) may keep > the good citizens (the Oracles of the world) good, but it won't shield > them from the actions of the citizens who don't know about or don't care > about our stability rules. Bad citizens can be arbitrarily bad. I don't want to drive the project team into doing something absurd to guard against fools, because fools are just too crafty. We've probably got better things to do. > I will point out that while this is simpler in the short run, in the > long run it may create other difficulties that make the cost comparison > not so obvious. For example, bfu and upgrade will need to be modified > to rename the node on upgrade. Bfu is just an internal tool. We deal with changes there all the time. Upgrade would be automatic, assuming the packaging is done correctly. > If the node is kept in the kernel, then > there are no upgrade implications. (And ultimately, each of those > approaches I mentioned could probably be implemented in less than 50 > lines of code.) Feel free to consult with the project team if you've got the time to do that and a good way to make this work. I've already specified the minimum conditions that I think hold for this to be a private interface: users can't stumble into it purely by accident as a consequence of using a famous path name. Any other solutions (including declaring /dev/dsp to be Committed now) are perfectly fine by me. -- 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
