Casper.Dik at sun.com wrote: >> While the solution we chose did introduce some bugs, it also avoided >> others and is actually reasonably high performance. > > And it raises about a call a week because people are confused by > this. (Or creates an email question on a Solaris forum, etc) > > By that standard, I'd call it a bad implementation. >
So by that standard, most of the new features in Solaris 10 are utterly broken, since they cause even more confusion :-). Realistically, taking away the system's ld.config from people would cause problems as well, and make us break an existing interface. Having a system-specific ld.config would have broken flash in exactly the same manner. And we'd be answering a question a week from various folks about why their process isn't using /usr/lib/libc.so.1. > That fact that people could lose system specified ld.so > config properties would be a bug; not a showstopper in > implementing such a solution. > And what exactly is a showstopper about the current situation? Or are we just talking about tradeoffs? If you don't delete and rebuild ld.config every time, your OS disk isn't portable between CPUs anymore. If you do, you wipe out user settings on every boot. We could add new search mechanisms for libc into ld.so.1, but that seemed rather special purpose. > People were screaming it was a bad solution and that > it would break stuff; the project team did not even > investigate; and it keeps on breaking stuff. > What does this "keep on" breaking? - Bart -- Bart Smaalders Solaris Kernel Performance barts at cyber.eng.sun.com http://blogs.sun.com/barts
