James Carlson wrote: > > Private, undocumented interfaces installed by default in Solaris > represent both unnecessary clutter, and an attractive nuisance for the > unwary. With some 14 megabytes in 2054 header files under > /usr/include, there's quite a bit of both in s10.
_IF_ some code _actually_ does "nothing" for _everyone_ then it should go. The "unwary" are a "nuisance" and not necessarily attractive either. :) Never give them the root password. > While undocumented and unsupported access to these interfaces should > be kept available for customers who don't mind living on the bleeding > edge, it should also be hidden by default for users who don't care and > who might be hurt. Who is providing / paying for support ? If you want to crash your own car into your own home, well... It's your car and your home. If you have a support contract with me, sign on as root and type rm -r / then your a fool to expect me to fix it for free, you fix it ... I like to be able to access my tools (even if undocumented and unsupported), if the hammer I buy does not come with instructions then I best know not to hit my thumb or to stay away from things that I don't know about. > Hiding Private Parts passwords > > INTRODUCTION > > This case presents a new policy for the inclusion of header files, > library links, and lint libraries in ON, and eases the transition > for the eventual removal of old, unused interfaces. Great. > In the past, header files and occasionally libraries as well have > been shipped in a somewhat haphazard fashion. Not Great. > Some are clearly required for standards compliance or are parts of > publicly documented proprietary interfaces. Many, however, represent > internal implementation artifacts and have no supported and > customer-usable content. If you run naked through the park I only must shield my children's eyes. That does not mean I want to look, then again, perhaps I do. > Worse still, customers are often generally unaware of our > distinctions among interfaces, and thus use 'grep' as a means to > locate usable symbols in /usr/include or 'nm' in /usr/lib. Because > we expose Project Private details in these files, and these details > can change in patches, unwary customers are at unnecessary risk of > breakage from Solaris patches. I grep / nm / locate all the time but please don't confuse me with the unwary customer nor force their restrictions upon me. I have root access because I compiled OpenSolaris (with Studio 12), I did the installation and I own the computer. I also do my own tech support prior to cluttering the forums with a foolish post and whining when no help is forthcoming. If you write a program that uses an interface that is undocumented then it makes sense to test for it's existence in your program by various means and to expect it to change or disappear (even while the program is running). > In some cases, where structures and definitions are included and used > within an application without reference to external symbols, appcert(1) > doesn't catch the problem. Over reliance on a single tool can be a problem. > More significantly, customers who stumble into the private > interfaces are generally unable to use these interfaces properly > without direct access to the system source code. Damn them. Swim, sink or stay out of the water. > Besides being unusable, these private definitions represent wasted > disk storage on every Solaris system, as well as unnecessary bloat > in patches. I do not enjoy "unnecessary bloat" but disk storage is cheap. If it really is entirely unused by anyone for anything then toss it. You would not want to break anything by tossing the wrong thing. I've had older OS's that worked and newer updated OS's with missing drivers that did not. > On the other hand, some customers either enjoy using unstable > interfaces or have business reasons to do so, and are able to accept > the fact that their code will be broken from patch to patch on > Solaris. For these customers, we should continue to deliver > undocumented details (to the extent that legal issues may allow). I'm running OpenSolaris b94 compiled with Sun Studio 12. I'm going to try compiling it with a 4.x series gcc - is that unstable enough 4U ? Short version: Toss some, keep most, hide none (from root). Thanks for your interesting post James. YT, Rob This message posted from opensolaris.org _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
