Newsgroups: comp.os.minix
Path: utzoo!utgpu!watserv1!hbetel
From: hbetel@watserv1.waterloo.edu (Heather Betel)
Subject: Re: Shared libraries with minix
Message-ID: <1991May28.035703.9271@watserv1.waterloo.edu>
Organization: University of Waterloo
References: <1991May24.015516.5698@watserv1.waterloo.edu> <3186@krafla.rhi.hi.is>
Date: Tue, 28 May 1991 03:57:03 GMT
Lines: 59

In article <3186@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes:
>hbetel@watserv1.uwaterloo.ca (Heather [actually Richard] Betel) writes:
>
>>        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!
>
>The library must have access to the dataspace of the current process.
>This is essentially the same as if the library routine is included
>in the codespace of the process like we use now.
>
	Its different. A library server runs in its own space, but to
access your parameters, it has to map in YOUR memory as well. This is
NOT essentially the same as before. IN the nonshared system, the
library functions are in your code space, but then, they also aren't
shared!(the whole point of the argument)

>>        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...
>
>What about a general purpose standard library which various
>language libraries then use. Most of the primitives and other
>general operations could be shared between different language
>libraries.
>
>Libraries can be categorised: system, application, user libraries.
>It is a good idea to standardise the interface to the libraries so
>that people can write custom libraries for their own use or for
>distribution which use the same library handling routines as the
>system does.
>
	A) PASCAL uses different calling semantics than C. Standardise
that! :-)
	B) C uses a completely different system for formatted io than
PASCAL. It is probably quite a task to reconcile the two. But if you
manage that, then try to then reconcile the two with FORTRAN! If you
can do that, why are you using minix? You should be able to make your
fortunes in AI or something...

>>        e) The original suggestion talks about putting in another
>>trap.   Why  do  that  when messages work?
>
>It is a question of efficiency. It is not desireable for a library
>routine which is called often in a tight inner loop to require a
>message rendevous each time it is called. It is only the first time,
>if the library section is not already present, that a message call
>is necessary so that the library section can be brought in from disk.
>
	Like a trap is any better. Instead of trapping, then copying
data, you just trap, then copy data! No matter how you cut it, there
will be a form of message passing with minix. Chack out how a serial
interrupt is handled. This won't be faster.

Richard