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