[224] in Release_Engineering
Re: notes for a proposal for a shared global library on the IBM RT/PC
daemon@ATHENA.MIT.EDU (Bill Sommerfeld)
Mon Aug 22 15:29:38 1988
Date: Mon, 22 Aug 88 15:27:18 EDT
From: Bill Sommerfeld <wesommer@ATHENA.MIT.EDU>
To: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
Cc: rel-eng@ATHENA.MIT.EDU
In-Reply-To: [222]
Just because something is simple doesn't mean it's right. What you
proposed, while very simple, would require much more work from release
engineering, and would greatly impede the ability to experiment with
new kernels and C libraries.
You _HAVE_ to be able to replace a shared library without recompiling
everything which depends on it--otherwise things just get far too hard
to manage. I would also argue that you need to be able to install a
new library without needing to reboot, by having multiple libraries
resident (you can do this on the RT by allocating another global
segment, and having something, perhaps in the environment, allow you
to override which segment to use).
While binding-by-name is one possibility, another possibility is to
assign opcodes to all of the calls in libc, and do some sort of
binding-by-opcode into a jump table/entry point vector at the start of
the shared library would involve a lot less `exec'-time overhead. Of
course, you'd have to come up with some sort of tool to build the
"stub" library which gets bound into every executable (perhaps this
could be built into the linker). [I should add that the Apollo
Domain/OS uses a system of global shared libraries similar to what
Mark Eichin proposed; the time necessary to do the binding by name for
small executables (/bin/echo and /bin/cat, which have 21 and 30
external references, respectively) is quite minimal (the full run time
of both programs is < .1 second on a DN4000, which is comparable in
speed to the "APC" model RT).]
Your message did contain a small grain of truth: no matter what we do,
there will be nontrivial effort involved in absorbing new releases
from Palo Alto, and the code will have to be thrown away in a timespan
of maybe three years when ACIS 4.3 disappears in favor of AIX or
OSFIX. It sounds like a neat project, but it is a lot of effort for
relatively little gain. If we could figure out some way to avoid
binding in the never-used software floating point emulation code, we
might be able to get almost as much of a gain in exchange for much
less work.
- Bill
