Shared system routines

[Michael.Young%cmu-cs-g at sri-unix.UUCP]

In order to allow shared modules, you'd also probably need a
global variable dictionary for each shared module.  [Unless
you choose to put the shared modules at *fixed* places in
every user's address space, which is not inconceivable on a Vax, 
for example.]  When a shared module wants to access a global
variable (which cannot be shared), it must look up
it's address in this "dictionary" (merely because the address
of the global variable may be different in separate users'
address spaces).  Likewise for shared modules calling external
routines.  Thus, inter-module calls and externals cost more.

Assuming the Unix non-shared disk structure (that is, a given
disk block is in one file only), you'd have to meddle with the
loader to handle the incorporation of these modules.  [That is,
not only the linker, which would generate references to these
shared code files, but the kernel loader which would interpret them.]
A big problem here is that changing one of these modules' code
files probably breaks everything that requires it.

A much simpler, but also a *lot* less flexible, approach would be
to make system-wide fixed-location libary routines.  *All* of these
routines would be at a known location in *every* process's
address space; kernel tables for such stuff could be limited
to once (instead of once per process).  Adb/sdb would have to
be taught that when looking up addresses in the shared area to
look in their own address spaces rather than that of the child/core-file.
The linker would have to be changed to understand the new addresses
for these things, but that's not too tough.  Again, the kernel's
loader would be the hardest change; I'm not sure how I'd deal
with page tables, but it could be done.  You'd probably have to
build some mechanism for changing the shared modules (like,
adding some, or even changing some without rebooting (!)); requiring
that all entries into shared modules go through an indirect
dictionary (even if it's from a non-shared module) would
help in that regard.

A nice idea, and one whose time has come, but not for Unix systems
probably.  Capability systems, as well as better virtual memory
systems, stand a much better chance of pulling this off.

			Michael