Shared libraries revisited

I found out a little bit about the Linux shared libraries in the mean
time, and I think it is not the way to go. They have several drawbacks:

  * Shared libraries have fixed addresses.
  * Inside shared libs global variables have fixed addresses. The
    manual encourages you to leave space after structures and arrays
    for future growth.
  * Making libraries is complicated and requires significant magic
    (such as rewriting gcc output to be more position independent).

I also agree, that PIC is probably too costly in terms of performance
(besides, gcc is rumoured to be very buggy when producing PIC code for
the 386/486).

So I still believe my proposal is best. To flesh it out a little bit:

Shared libraries are stored in relocatable format (output of ld -r).

As Andy suggested, there should be a server to manage them. I am not
yet sure, how they should be registered to the server:
 * Some program to tell the server which libraries exist. For standard
   libraries this would have to be called from /etc/rc (or even
   boot.lst).
 * The server searches some path for library files. There must be a
   method to tell the server to change or rescan the path).

 personally, I like the first method somewhat better.

When the server knows that a library will be needed (either when the
first program asks for it or when it is registered) it chooses some
unique address and relocates the library to this address. It then
announces the address, and all processes which need the lib can mmap it
into their process space at this address. Care has to be taken to
get protection right.

Since the position of the libraries is generally not known at compile
time, the executables must be stored in relocatable format also (or
alternatively, they must only use pointers to access library objects --
I don't like that). This may make demand paging infeasible. Also, since
I don't think it is a good idea letting the process patch up itself,
the mmapping of the shared libraries should not be done by by the
process itself.

I see two problems with this approach:

 * Startup times may be slow, although I don't really think so. If it
   really proves to be slow, we can always put the standard libs at
   fixed addresses and prerelocate the executables (I think this is
   what is called `presnapping' in Primos).

 * It is not possible to override parts of a library. If you include
   a different version of e.g. fprintf in your program, the library will
   still use its own version. Actually I am not even sure if this is a
   disadvantage :-)

Apart from the obvious question (Have I overlooked something?), I have
a few others:

How are processes created currently?

What happens if a process sends more data than the receiver expects?
The comments in msg.h and seg.c imply that one or more segments
containing the surplus data is created. The code however looks like it
is discarded (all segments of the message are mapped to the receiver's
address space, as much data as fits is copied to the segments specified
by the receiver, all segments of sent message are discarded).

What is port 0x84? It is used in the assembler code a lot (in the SYNC
macro). My hardware docu (for a not 100% compatible XT :-) just says
`DO NOT USE!'.

-- 
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Computer Science/Real-Time Systems    | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |