Garrett D'Amore wrote: > James Carlson wrote: >> Think of it as linker mapfiles for packaging. The idea, unfortunately, >> went nowhere. Too many people were either skeptical of the utility of >> breaking up SUNWhea or of the value of trying to segregate private >> interfaces better. >> >> > I'm not of the opinion that breaking up SUNWhea into smaller packages is > useful. I *am* of the opinion that headers which are Project Private, > or possibly Consolidation Private, should not be packaged at all. (I'd > probably grant a special exception for Consolidation Private interfaces > which are *intended* for public consumption at some future date, but > even that could probably just as easily be dealt with by a future push > after ARC approves the interfaces for public consumption.)
That's not how Sun has done things historically. Things are added to SUNWhea on project team whim. Sometimes headers that have nothing to do with anything at all (<net/af.h>, anyone?) are delivered. Sometimes things that include private implementation details are there. It's a potpourri. The point of architecture isn't (and hasn't been) to keep "secrets;" it's to define what should and should not be used as a matter of _documentation_. The distinction is important. Finding a random file on the system doesn't give you any special guarantee that the contents won't blind you or drive you mad. Read through CR 4696464 for some of the history on this. > I suppose at one point having those headers on the system was useful for > debugging back when people had to manually work out structures in adb. > These days with CTF they are completely unnecessary. Whenever I easily > I can, I remove project private (especially *driver private!*) headers > from packaging. I think you're at least partly swimming against the tide. I agree that it'd be nice to have some clearer delineation, but outright removal isn't quite the norm. Only omitting *documentation* has been the norm. One other important use, besides adb, is for third party software that (knowingly or not) violates the undocumented interfaces. This is unfortunately extremely common, simply because the set of documented interfaces is a subset of the *NECESSARY* ones. And when faced with delivering a product for revenue versus obeying obscure architectural advice from Sun, guess which one wins? The system is unfortunately rife with this sort of stuff. The VM/VFS interfaces are just the tip of the iceberg. -- James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
