Garrett D'Amore wrote: > Roland Mainz wrote: > > James Carlson wrote: [snip] > > Why (again I am thinking more about the stack/list/queue/tree/etc. > > infratructure and sfio (these are the major items of libast)) ? > > I believe that if these functions are of such core utility, that they > should be added to libc itself. IMO, as an outsider, I've not been too > happy with the way some of the extra "bolt-ons" (c.f. libadm.so) have > been handled, as undocumented (or poorly documented) functions, which > require extra linker flags to get at, and which are often not available > outside of ON. > > Much better, IMO, to fully promote generally useful shared routines into > libc.
I disagree here slightly - the functions should only be put into libc if they are generally usefull for the majority of the applications. I really do not want to turn libc into a giant dumping ground for everything. If parts of libast turn out to be very usefull for the majority of applications then it should be made part of the next POSIX standard and only then moved into libc (or short: First standardise and then move to libc. Any functionality not part of a particular standard should reside in seperate libraries (otherwise we could start moving libmozjs.so (Mozilla JavaScript engine) into libc... =:-) )). > Plus, that makes it possible to use these functions inside libc > implementation as well, perhaps gaining even further benefit. Ok, but one of the major disadvantages is that we can't change such utilty functions on demand (which we could do for libast since it is currently project private and then only parts of it receive a higher stability level (e.g. project private for OS/Net, consolisation private or whatever comes next then (disclaimer: I am not an expert in this area and usually cause havoc and devastation by using the wrong terms... ;-( ))). Once they are made a "standard" (or better: the "stability level" within Solaris is beyond a certain barrier) they cannot be changed anymore (easily; Solaris's gurantee for backwards-compatibility makes this even more difficult than on other operating systems) and I'd like to limit any function movements to libc to those mandated by a standard (like POSIX). libast is after all an _utility_ library where parts of it are changed on demand and others are rock-solid (like sfio). [snip] > I would further conjecture that this is some of the reason that > libraries like libthread, libnsl, and maybe others have become "shells", > with all the real functionality in libc. At least libnsl and libsocket are still seperate libraries since they are far too big (and IMO they should remain seperate since not every application needs networking) and AFAIK the reasons for moving librt/libaio/libthread to libc were more about implementation issues (Mike/Casper/etc. may provide more details and/or correct me if I am wrong... but AFAIK for librt/libaio there were some issues with the dynamically loading symbols or something like that...). For other libraries like libw (since multibyte support is more or less mandatory for all application in Solaris) you're right... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) [EMAIL PROTECTED] \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;) _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
