Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!emory!gatech!udel!mmdf
From: tsarna@polar.bowdoin.edu (Tyler Sarna)
Newsgroups: comp.os.minix
Subject: Re: Shared libraries with minix
Message-ID: <54886@nigel.ee.udel.edu>
Date: 29 May 91 02:17:41 GMT
Sender: mmdf@ee.udel.edu
Lines: 61

Heather Betel didn't write:
> 
>         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.

This is actually an almost perfect description of how shared
libraries work under Exec, the hunk of Amiga OS that deals with
multitasking and so forth. The Exec scheme is slightly fancier,
but the basic concept is the same. This scheme is very
attractive from a efficiency standpoint. It also allows the
library to be unloaded when no processes that use it are
running.

>         On the 8086, however, this isn't  much  good.  We  either

This is the main stumbling point. I don't see a clean way to dit
it on the 8086. IMHO, the solution is to rid the world of
8086's, but I don't think that suggestion will go over well here :-)

>         c) How do you select which lib function  you  want?  This
> could  very  well  end up looking like the IOCTL call, with about
> 200 functions being hung off a single integer.

A much simpler solution is to just have the functions at a
well-known offset from the lib pointer.

>         d) where do you draw the line  between  what  is  put  in
> these  libraries,  and  what isn't? The pascal runtime library is
> just as important as the C libraries. Are you  going  to  put  in
> both?  How about the LISP, FORTH, ADA, etc libraries. How about C
> libraries that aren't in libc.a? (eg:curses) The list could go on
> forever...

You've overlooked one ofthe main advantages of your own scheme!
The library name is specified at runtime. Pascal (LISP, Draco,
whatever) programs simply open the appropriate library by name.
If noone else is using it, the library is loaded. When the
program closes the library (as part of _exit), the library is
unloaded if the use count is zero. Unneeded libraries can be
removed from the system, and new ones added when required. New
versions of old libraries can be installed without recompiling
the programs that use them, too.

>         e) The original suggestion talks about putting in another
> trap.   Why  do  that  when messages work? If we are going to use
> message passing, we should use it  all  the  way.  Otherwise,  we

The reason for not doing this is the large performance hit
involved in copying the messages.

-- 
Tyler "Ty" Sarna                            tsarna@polar.bowdoin.edu

           "Death therapy, Bob. It's a guaranteed cure."