Shared Library Objectives (Was: Shared Lib Question (ISC))

[Larry Philps]

In <1991May11.011213.4846 at NCoast.ORG> allbery at NCoast.ORG (Brandon S. Allbery KB8JRR/AA) writes:

> As quoted from <162 at titccy.cc.titech.ac.jp> by mohta at necom830.cc.titech.ac.jp (Masataka Ohta):
> +---------------
> | In article <276 at rwing.UUCP> pat at 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 at sco.COM  or larryp%scocan at uunet.uu.net
UUCP:	 {uunet,utcsri,sco}!scocan!larryp
Phone:	 (416) 922-1937
Fax:	 (416) 922-8397