Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!henry From: henry@utzoo.UUCP (Henry Spencer) Newsgroups: comp.os.minix Subject: Re: File system/virtual memory integration Message-ID: <7730@utzoo.UUCP> Date: Mon, 2-Mar-87 20:59:34 EST Article-I.D.: utzoo.7730 Posted: Mon Mar 2 20:59:34 1987 Date-Received: Mon, 2-Mar-87 20:59:34 EST References: <1276@husc6.UUCP>, <1057@ius2.cs.cmu.edu> Organization: U of Toronto Zoology Lines: 28 Keywords: file system,virtual memory,Multics > I was wondering how difficult it might be to 'integrate' virtual memory > with the file system process. I'm told that the Multics operating system > mapped a file into the virtual address space when it was opened. Multics did indeed do that. The problem is that the ability to do tricks like that is *very* dependent on good memory-management hardware. That's why Unix doesn't do it. An 8088- or 8086-based machine has no hope of doing it. Nor does a bare 68000 as in the ST. The somewhat better MMU in the 80286 just might make it possible in a sleazy and inefficient way on an AT. You really need paging to do it right, and it better be a well- designed paging box at that. > Would this be of any advantages (smaller code size, simpler semantics?) > in a Minix-based system? If anything it complicates the code and the semantics. For one thing, it's not clear how you can do such mapping for non-ordinary files -- directories, devices, and so forth. For another thing, even with a cooperative MMU it becomes very difficult to maintain a file size down to the byte when the MMU only works down to the page. In short, it's an interesting concept but a whole new can of worms. If you are looking for a neat experiment, go ahead. If you are looking for a simple way to improve Minix without introducing serious incompatibilities, forget it. -- "We must choose: the stars or Henry Spencer @ U of Toronto Zoology the dust. Which shall it be?" {allegra,ihnp4,decvax,pyramid}!utzoo!henry