[226] in Release_Engineering
notes for a proposal for a shared global library on the IBM RT/PC
daemon@ATHENA.MIT.EDU (Mark Lillibridge)
Mon Aug 22 16:43:18 1988
Date: Mon, 22 Aug 88 16:42:55 EDT
From: Mark Lillibridge <chariot@ATHENA.MIT.EDU>
To: wesommer@ATHENA.MIT.EDU
Cc: rel-eng@ATHENA.MIT.EDU
In-Reply-To: Bill Sommerfeld's message of Mon, 22 Aug 88 15:27:18 EDT <8808221927.AA03685@ra.mit.edu>
Reply-To: chariot@ATHENA.MIT.EDU
> 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).
Sigh. Maybe I'm just slow or something but I don't find that
argument compelling. Could you please explain WHY "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."
Likewise, for your other claims. (So I'm dense -- here's a chance to
practice your comminication skills...)
As I understand it, the operation of "replacing a shared
library" corresponds in the current setup (i.e., 6.0C) to recompiling
everything on the packs. I.e, "replacing a shared library without
recompiling" is not currently supported. So if we _HAVE_ to be able to
do this, how is it that release engineering can do anything now at all?
You can easily install a new library for user programs under my
proposal simply by doing a "cp". I.e., cp libc.a /usr/lib/libc.a.
This, of course, is assuming you can write to the packs...
> 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.
Why? You can replace the kernel at any time without problems so
long as it still has the shared library feature. (Remember, the shared
libary resides on disk seperately from the kernel) If you want to try
out a new C library, simply link with it instead of the standard one.
You are argueing that since my proposal does not let us do
things that we can't do now, it is no good. A valid reason for tossing
my proposal would be either it doesn't do something that we can
currently do or it doesn't have a feature that would be really nice to
have that could be gotten by just.... For example, my proposal assumes
that it is ok to not allow the users to use the shared library. An
argument that the space saved by allowing users to use the shared
library is sufficent justification for the extra complexity and speed is
a reasonable argument. My position is that this is not the case and
hence my proposal.
- Mark
