From: drew@hamlet.cs.colorado.edu (Drew Eckhardt) Subject: Dynamic linking Date: 2 May 1992 20:29:56 GMT
I patched my kernel to do dynamic linking of any OMAGIC a.out files, instead of
returning -ENOEXEC.
Right now, I have a program /lib/dld which makes the appropriate calls to
ld to get it linked if it isn't already linked, and executes the right
linked image in anycase - but that will find its way into the kernel if
any one can convince me that dynamic linking is a Good Thing (tm).
When an OMAGIC file is encountered, it's file name is
passed as argv[argc] to /lib/dld. /lib/dld decides on a temporary filename
for it, equivalent to /exec/%04x/%04x:%08x, where the directory under
/exec is the device number, and filename device number : inode number,
providing a unique name for every executable. If this file exists,
it is run, otherwise ld is called with the right strings and drops a copy there,
which is then run.
The performance impact is negligible iff copies of the shared library stubs,
linker stub (crt0.o), /lib/dld and ld are in buffer cache for unlinked programs,
/lib/dld for linked programs.
Advantages :
- You don't have to get new binaries to fix any corrected library bugs.
- People can safely distributed everything as an OMAGIC file, which can
be run "out of the box" or statically linked to shared library stubs.
Disadvantages :
- If the shared library stubs, etc are not in buffer cache (this will be
rectified if we get an MFS) performance will be slow.
- You need disk to keep a linked version of the program around so you
can swap to it. Again, an MFS could rectify this,
but you are still using 100% extra disk / swap / memory someplace.
- If interfaces change to any library function, you are toasted.
- If the loaded copy isn't still around, everytime the program is run
you have the ld delay...
A MFS (memory based filesystem, as used in post Reno 4.3 BSD, like a ramdisk,
only it is pageable) on which /exec is mounted would increase swap requirements,
but eliminate the /exec disk space requirement, and a mfs file system sort of
acts like it has its own buffer cache - so your chances of having library
stubs, etc in core are greater and you don't have the performance problems
that come from loading those.
Any comments as to an MFS, how long to keep the linked image around for,
etc are welcome, as comments on weather the disk space needed for the
linked image of every program running (each program, not each instance)
around is worth it - this is what determines if I clean up the code and
make it public.
Bugs :
fork'ing and exec'ing a second OMAGIC program
from an OMAGIC program dumps core for some reason, should be easy to fix.
I have find | perl run every five minutes to clean up /exec,
and that needs to change to the kernel keeping track of activity in omagic
files, and deleting the linked version X minutes after the inode i_count
field reaches 0.....