>Ouch... Ok... >... some notes/questions for that work: >1. It would be nice to move ONLY the current POSIX-based and other >standards-based functionality (Unix98 etc.) libnsl+libsocket functions >to libc and keep all the compatibilty-wrapper stuff in libnsl/libsocket >to avoid that libc gets bloated with 20years of Unix >backwards-compatibility workarounds
Why? This would make building software on Solaris much more complicated; also, one motivation for earlier mergers into libc (libthread, libdoor, librt/posix4) was the large number of private interfaces between those libraries and libc; such intimate knowledge caused all kinds of problems. Separating out the wrappers from the actual code (and the wrappers would amount to a small percentage only) would require the addition of a ton of additional private interfaces. One of the issues of such private interfaces is that the private interfaces are visible to applications. >2. Maybe [1] could be extended to the non-reentrant/threadsafe versions >of some functions, e.g. |gethostbyname_r()| moves to libc, >|gethostbyname()| remains in libnsl (OkOk, this is just >dreaming/wishfull thinking... but such a "split" would avoid adding more >global read/write data to libc and may even influence application >programmers to use the |*_r()| interfaces by default) This seems to be putting the horse behind the wagon. >3. What are the reasons for such a "fold" ? As meem said "because no-one else has this split and it makes developing code harder"; there are also private interfaces which can then be eliminated. >4. What about (as alternative propsal OR executed as part of the >"folding") to compile the libnsl/libsocket code with "-xstrconst" + some >further linker magic to reduce size of the data which need to be >duplicated for each process ? No issue at all. With gcc builds, string constness should be reasonably well tested by now. This will not, I fear, impact the libnsl data consumption greatly. _______________________________________________ opensolaris-code mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
