Newsgroups: comp.os.minix
Path: utzoo!utgpu!watserv1!hbetel
From: hbetel@watserv1.uwaterloo.ca (Heather Betel)
Subject: Shared libraries with minix
Message-ID: <1991May24.015516.5698@watserv1.waterloo.edu>
Sender: hbetel@watserv1.waterloo.edu (Heather Betel)
Organization: University of Waterloo
Date: Fri, 24 May 1991 01:55:16 GMT
Lines: 80

        First off, I have to appologize to the guy who  suggested
putting  the  library  into  the  kernel. My message reads like a
flame, and I didn't want that. Anyhow, please don't take offense,
and  I'll  try  not  to  write  follow-ups while I am still over-
reacting :-).
        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.
        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.
        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.
        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.
        On the 8086, however, this isn't  much  good.  We  either
have  to do a far call, or tack the libraries onto the end of the
code segment.  The former won't work with the existing  compiler,
and the latter does not meet goal number 2.
        So there you are. That is my solution. With the  8086,  I
would  get someone to rewrite the C compiler. Actually, that's my
summer project. Its my first compiler, and since all  I  have  is
lots  of  reference  books  to  go  on, it won't be great, but it
should be very readable. It SHOULD be an ANSI C compiler for any-
thing  I  want, but that may end up being too ambitious, so I can
say that it'll start out for the 8086, and I hope to move it over
to the 88k, and maybe the 68k on the way...
        Lastly, I should point out why *I*  don't  want  the  li-
braries in the kernel:
        a) it doesn't achieve goal #4. To me, that says it is not
a  very  well thought out solution. Mine goes a step further, and
works for most hardware, including some that DON'T have  an  MMU,
so  I  can state that THERE is a better solution than putting li-
braries in kernel.
        b) How do parameters get passed? The  library  MUST  have
access  to  all  processes' data space (can you feel your stomach
churn?) On an MMU, this means all dataspaces  for  all  processes
are mapped into the lib server's dataspace!
        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.
        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...
        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
might  as  well  just start mapping all the system calls onto the
various interrupts available. That gives us  about  246  possible
system calls on the PC, or 16 on the 68k.


 
Richard Betel
-------------------------------------------------------------------------
In a world of steel and ferroconcrete, it takes a stainless steel rat
to hide between the walls.
-------------------------------------------------------------------------

