Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!isgate!krafla!adamd
From: adamd@rhi.hi.is (Adam David)
Newsgroups: comp.os.minix
Subject: Re: Shared libraries with minix
Message-ID: <3216@krafla.rhi.hi.is>
Date: 30 May 91 20:59:13 GMT
References: <1991May24.015516.5698@watserv1.waterloo.edu> <3186@krafla.rhi.hi.is> <1991May28.035703.9271@watserv1.waterloo.edu>
Organization: University of Iceland
Lines: 54

hbetel@watserv1.waterloo.edu (Heather [actually Richard] Betel) writes:

>In article <3186@krafla.rhi.hi.is> adamd@rhi.hi.is (Adam David) writes:
>>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)

I was not clear enough. I meant conceptual sameness in the operation
of the program code (what gets done, not how it gets done), I am aware that
the implementation mechanism is markedly different and carries with it some
non-trivial issues.

The library server has temporary access to the dataspace of the client
which initiated the library call, because the library routine is executed
with the user and group ID of the client. The client process has temporary
access to the library codespace in order to access the library routine.

In fact an implementation is conceivable where all the server has to do
is notify the MM that the access is a valid library call and therefore
to be allowed. By restricting the codespace access to the current library
section during each library call, there is little to no danger of one process
treading all over another one due to a badly written library routine. This
would seem to require full message-passing though, unless the interaction
between library server and MM is very special.

>	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!

I am talking about fundamental operations, and not calling conventions.
The language-dependent part is in the language-specific library and the
part which can be shared between languages is in the general (utility)
library.

>	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. Check out how a serial
>interrupt is handled. This won't be faster.

Maybe I misunderstood. I was under the impression that the trap handler
was guaranteed maximum priority which would be higher than normal IPC
messages.

>Richard

Adam