Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!samsung!munnari.oz.au!metro!dmssyd.syd.dms.CSIRO.AU!ditsydh.syd.dit.CSIRO.AU!evans From: evans@syd.dit.CSIRO.AU (Bruce.Evans) Newsgroups: comp.os.minix Subject: Re: Shared libraries with minix Message-ID: <1991Jun3.150509.10582@syd.dit.CSIRO.AU> Date: 3 Jun 91 15:05:09 GMT References: <3216@krafla.rhi.hi.is> <1991Jun1.043438.17038@watserv1.waterloo.edu> Organization: CSIRO Division of Info Tech, Sydney, Australia Lines: 36 In article klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: >In <1991Jun1.043438.17038@watserv1.waterloo.edu> hbetel@watserv1.waterloo.edu (Heather Betel) writes: > >>... >>space. Mapping in the client's space, doing the work, then mapping it >>out, for every call is expensive. > >Either i don't understand the problem, Richards idea of an MMU is too >simple, or my idea of an MMU is too complex ;-) > >It should be possible for an MMU (040 type) to have more than 3 segments >allowed to one process at one time. The segments which need to be in >current address space, and not causing a trap are (IMHO): >1) user program. text, data (incuding bbs) and stack. >2) trap handler. At least text. Perhaps data. Stack? >3) Shared library code. At least text. Perhaps read-only data. With a decent MMU, the library code can be mapped into all processes at the same time at some convenient address such as 0xC0000000. It is easy to set up direct calls from user code to library code. With a 68000 and no MMU, the same scheme will work (for calls) using some less convenient (small) address. Even with an 8086, far calls could be used (near calls to stub routines that make far calls - there is the major inconvenience that the code segment will mess up the stack frame). Relocation of data is much more difficult. How can shared code handle different data addresses? Pointers take care of many cases. But what happens deep in an fprintf call when a buffer has to be mallocated? malloc needs a global variable to start from, and it is too much trouble to add it to the fprintf interface. On systems with an MMU and on 8086's, such variables can be put at conventional locations in low memory, e.g., at 0x40000000, 0x40000004, ... for the MMU case and 0, 4, ... for the segmented (split I&D) case. For 68000 systems with no MMU, I don't see a good way to tell where the are. -- Bruce Evans evans@syd.dit.csiro.au