Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!samsung!sol.ctr.columbia.edu!caen!umich!vela!m.cs.uiuc.edu!wuarchive!decwrl!uunet!email!vmars!hp
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Newsgroups: comp.os.minix
Subject: Re: Shared libraries with minix
Message-ID: <1991May24.130356.29572@email.tuwien.ac.at>
Date: 24 May 91 13:03:56 GMT
References: <1991May24.015516.5698@watserv1.waterloo.edu>
Sender: news@email.tuwien.ac.at
Distribution: "world"
Organization: Technical University of Vienna, Dept. for Realtime Systems
Lines: 66
Nntp-Posting-Host: nowhere.vmars.tuwien.ac.at

hbetel@watserv1.uwaterloo.ca (Heather Betel) writes:

>        To the issue at hand. The best place to start is  to  de-
>fine some goals. The shared library is a way to:
>        1) minimize wasted space  on  disk  from  duplication  of
>	   binaries.
>	2) minimize wasted memory from duplication of binaries.
>        Obviously, we want to have all processes share  the  same
>memory  image  of  the  libraries,  which is loaded from a single
>file.
>        This is where we all agree, but every one seems  to  have
>stopped  here  at  defining golas. There is one more issue: MMUs.
>(3)The final solution should not *REQUIRE* an  MMU,  but  (4)  it
>should take advantage of one, if it is available.

Agreed.

>        Rather than find a solution for non-MMU systems, then try
>to adapt it, I think we should find an MMU-friendly solution, and
>adapt IT to the non-MMU systems.

Agreed.

>        I have a solution in mind, but I am not sure I  like  it.
>It  works  beautifully  on MMU systems (I think), and is probably
>pretty good on the 68k, but it seems impossible,  sick,  or  both
>for the 8086.

I think it is just the other way round (although you have to change the
compiler on the 80x86)

>        What I think we should do is put in another  system  call
>that  is  passed  the  file  name  of a library. It will return a
>pointer to the start of the library.
>        On an MMU system, the loaded library can be  mapped  into
>the  process'es  addressing space, and can also be shared between
>programs (I *THINK* all MMUs let  you  share  pages  between  two
>processes).
>        On the 68K, this is exactly the same, except  every  pro-
>cess gets the same pointer.

How do you decide where to map your library into the processes' address
space? If you have two libraries and three processes, one of which uses
library A, one B, and one both, do A and B start at the same address in
all processes that use them? You will get large holes this way (which
doesn't matter much if you use paging anyway), and worse, your program
might grow beyond the address that is reserved for the first library.
On the other hand, if you use a different start address for the library
for every process you might have to relocate the library for each
process and thus you can't share the text image between processes. You
won't conserve memory space this way, only disk space.

On the 80x86 this is not a problem if you use far pointers for
passing data between libraries and far calls, and near pointers/calls
if you stay within a library, and on other machines you can simulate
this with base pointers, but I guess this makes either writing shared
libraries awkward or you have to play nasty tricks with the
compiler/linker (I once wrote a shared library for OS/2 -- yuck).

How are these problems solved on existing UNIXes with shared libraries?

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