Re: Shared libraries?

>Note that shared libraries really need to be done properly, if they're
>to be done at all. Some of the Linuxers here could tell long tales
>of woe with the early versions on Linux shared libraries... and can
>probably tell how to avoid the mistakes.

There are two levels of answer to this question. The first has to do
with the "kernel" functionality which happens to be present in the C
library due to the design of a microkernel. The second has to do with
user code which would be nice to share.

For the former ("kernel") code, I would rather use a simpler mechanism
that Sun-style shared libraries. Sun-style (from my research; somebody
correct me if I'm out of date) generates slower code and burns one of
those valuable 386 registers. For "kernel" user-mode code, I would rather
use a technique more like the original Linux shared libraries.
Perhaps not even call it a shared library; we could refer to the ring 0
"kernel" as k-code, and ring 3 "kernel" as u-code. u-code would be
attached at a fixed address at bootup with your usual leading jump table
to get to the various functions. When you boot a kernel you run your
programs with the loaded version of both k-code and u-code.

This then leaves all the rest of the libraries and their functions.
If somebody wants to hack up the libraries, write an ld.so, and all
that good stuff, then I think that's fine. Just make sure the -static
still works so we can generate non-shared versions as needed!

Most studies suggest that the savings in memory is not very great.
The big savings is in disk space and in convenience in having your
app dynamically run against the latest (and presumably best) version
of the various library routines.

                                        Andy
Received on Wed Aug 18 08:24:16 1993