Rob (and everyone else): Removal of "private and undocumented headers" from the delivered distribution will never prevent you from having access to those bits that are part of the source product.
Please don't confuse *source* code with the delivered headers used for "normal" software engineering. As to those people who want to do tricky things with dtrace and such.... if you have the source you can still do so. If you *don't* have the source, then you're probably only fooling yourself if you think you know how and where structures are used. The headers alone are too incomplete a picture. (So, that means, you probably should have the source code.) To use your illusion of the car... when you buy your vehicle, it does not include blue prints for the engine, or even specifications for major parts (can you find the spec for your timing chain/belt in your owner's guide?) If you want that information, you can take an extra step, and get a maintenance manual. Its not unreasonable for us to provide the headers (along with the rest of the source) for download. Its not clear to me that they need to provided in neat and tidy shrink wrap packaging, and deliver a copy of them by default with every download or installation. Headers that aren't part of public interfaces are bloat, do cause confusion (which portions of the interfaces can you safely use or rely upon?) and frankly the effort to package them and deliver them (other than as part of the full source code) does not come for free. We're better off, IMO, not packaging such headers. -- Garrett Rob Clark wrote: > 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 > _______________________________________________ opensolaris-code mailing list opensolaris-code@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
