larryp@sco.COM (Larry Philps) (05/13/91)
In <1991May11.011213.4846@NCoast.ORG> allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/AA) writes: > As quoted from <162@titccy.cc.titech.ac.jp> by mohta@necom830.cc.titech.ac.jp (Masataka Ohta): > +--------------- > | In article <276@rwing.UUCP> pat@rwing.UUCP (Pat Myrto) writes: > | >I have noticed with interest the discussion going on regarding shared > | >libraries. However, what is obvious is that there are several kinds > | >of shared libaries, all using some different scheme to operate. > | > | It proves that the concept of shared libraries is not so simple. > +--------------- > > No, it proves that anything, regardless of its simplicity, can be made > arbitrarily and unnecessarily complex. SVR3 shared libraries are a pretty > good example of that. But it does NOT mean that any given complex > implementation is proof that the *concept* is complex. > > Quite aside from the other complexities underlying such things as varying > shared library implementations: marketing decisions, for example. Now > THERE'S a complex system for you to try to unravel. Good luck --- you'll need > it. Actaully, I think part of the reason there are so many implementations is that there are so many conflicting goals. Just what do you want from your shared library system? Possibilites: (Note, by ATT, I mean AT&T SVR3 shared libraries) 1) Ability to easily create a shared library: yes) Do it like Sun, pic code and dynamic linking no) Don't worry about it, use something that enhances your other goals. (like ATT: creating a shared library is a nightmare) 2) Fast Startup times: yes) Do it like ATT, no pic code, no dynamic linking, exec just sets up the regions and lets it rip. no) Don't worry about it, let ld.so (or whatever) run, and set things up. 3) Fast execution: yes) Most processors run pic code slower than absolute code, so you probably pick the absolute method. no) Are you willing to live with the performance degradation in order to satisfy your other goals? 4) Maximum Memory sharing between processes yes) pic and absolute code should be equivalent if you are clever. Ensure the dynamic linker does not fault in most of the library while patching global data addresses. If you used absolute code, you should be able to get away with copy-on-write shared data segments. no) Right, memory is infinite in size and free anyway ... right? 5) Easy maintenance yes) Want to be able to create new versions easily, update the libraries with fixes/features without requiring program recompilation. Want to be able to link an arbitrary set of libraries together without worrying about address conflicts. Pic and dynamic linking wins here. no) Don't worry about it, use something that enhances your other goals. However, if you do it like ATT, you still have to be very careful picking your shared library load addresses to utilise *virtual* address space efficiently. These are the result of some intellectual lunches I had with a friend. They took place a while ago so I might have forgotten a goal or two. I would say AT&T picked goals 2 and 3, and maybe 4. Sun went the 1, 4, and 5 route. OSF seems like a 1 and 5 system, I am actually not sure how the dynamic program loader affects 3 and 4. We did not come up with an implementation that satisfies all the above goals. Anybody know of one? --- Larry Philps, SCO Canada, Inc (Formerly: HCR Corporation) Postman: 130 Bloor St. West, 10th floor, Toronto, Ontario. M5S 1N5 InterNet: larryp@sco.COM or larryp%scocan@uunet.uu.net UUCP: {uunet,utcsri,sco}!scocan!larryp Phone: (416) 922-1937 Fax: (416) 922-8397
blarson@blars (05/14/91)
In article <1991May13.144438.21103@sco.COM> larryp@sco.COM (Larry Philps) writes: Hmm, let's compare Primos shared libraries... > 1) Ability to easily create a shared library: > yes) Do it like Sun, pic code and dynamic linking Yes. Creating a shared libarary takes one or two more linker command than a normal program. > 2) Fast Startup times: > yes) Do it like ATT, no pic code, no dynamic linking, exec > just sets up the regions and lets it rip. > no) Don't worry about it, let ld.so (or whatever) run, and > set things up. Sort-of. Start-up is reasonably fast, but the first time each shared routine is called it is dynamicly linked. Registered EPFs are available at Rev 23 to allow pre-linking of frequently run programs. (At cost of some of the other points.) > 3) Fast execution: > yes) Most processors run pic code slower than absolute code, > so you probably pick the absolute method. Yes. Reasonably written segmented code doesn't care which segment it is loaded in. > 4) Maximum Memory sharing between processes > yes) pic and absolute code should be equivalent if you are > clever. Ensure the dynamic linker does not fault in most > of the library while patching global data addresses. Yes. > 5) Easy maintenance > yes) Want to be able to create new versions easily, update the > libraries with fixes/features without requiring program > recompilation. Want to be able to link an arbitrary set > of libraries together without worrying about address > conflicts. Pic and dynamic linking wins here. Yes. Also a single user can test out new version without affecting other users. >We did not come up with an implementation that satisfies all the above >goals. Anybody know of one? Primos seems to come close. A couple of minor details are the required hardware support (fault bit) and the many other problems of Primos. (They still havn't figured out how to do I/O reasonably.) -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.
rbunten@micrognosis.co.uk (Rob Bunten) (05/16/91)
In article <1991May13.144438.21103@sco.COM>, larryp@sco.COM (Larry Philps) writes: >Actaully, I think part of the reason there are so many implementations is >that there are so many conflicting goals. Just what do you want from your >shared library system? > >Possibilites: (Note, by ATT, I mean AT&T SVR3 shared libraries) > > 1) Ability to easily create a shared library: > 2) Fast Startup times: > 3) Fast execution: > 4) Maximum Memory sharing between processes > 5) Easy maintenance > >These are the result of some intellectual lunches I had with a friend. >They took place a while ago so I might have forgotten a goal or two. One you haven't mention is reduction of on-disk program size. One of the rumours I've heard is that Sun introduced shared libraries to reduce the number of tapes needed for OS upgrades.
guy@auspex.auspex.com (Guy Harris) (05/20/91)
>One you haven't mention is reduction of on-disk program size. One of the >rumours I've heard is that Sun introduced shared libraries to reduce the number >of tapes needed for OS upgrades. Rumors are always a source of entertainment. Yes, a reduction in disk space usage was one of the reasons for doing shared libraries in SunOS 4.x; other reasons were to allow more code sharing without having to introduce gross hacks like "toolmerging", and to provide a general dynamic-linking capability.