Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!utrcu1!mi.eltn.utwente.nl!klamer From: klamer@mi.eltn.utwente.nl (Klamer Schutte) Newsgroups: comp.os.minix Subject: Re: Shared libraries with minix Message-ID: Date: 3 Jun 91 07:53:52 GMT References: <3186@krafla.rhi.hi.is> <1991May28.035703.9271@watserv1.waterloo.edu> <3216@krafla.rhi.hi.is> <1991Jun1.043438.17038@watserv1.waterloo.edu> Sender: news@utrcu1.UUCP Organization: University of Twente, BSC-El Lines: 34 In <1991Jun1.043438.17038@watserv1.waterloo.edu> hbetel@watserv1.waterloo.edu (Heather Betel) writes: > My point is that this must happen even on MMU systems. On the >8086, your model is fairly simple, but under, say, an 040, the library >server is a different process, with a completely different memory >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. This makes 5-8 segments. The standard m68k MMU (Not on chip! ;-) has 16 segments (from memory, from structured computer organisation, Dr Tanenbaum, first edition). So no remapping on every call should be needed! > The harddrive controller uses IPC. Are you going to give the >library server higher priority than the harddrive? I hope so. The kernel harddrive driver might call library routines as well... Klamer -- Klamer Schutte Tel: +31-53-892786 Fax: +31-53-340045 Faculty of electrical engineering -- University of Twente, The Netherlands preferred: klamer@mi.eltn.utwente.nl SMTP: klamer@utelmi01.el.utwente.nl