Path: utzoo!attcan!uunet!fernwood!apple!sun-barr!cs.utexas.edu!wuarchive!emory!att!news.cs.indiana.edu!noose.ecn.purdue.edu!ecn.purdue.edu!cyliax From: cyliax@ecn.purdue.edu (Ingo Cyliax) Newsgroups: comp.os.minix Subject: Virtual memory Minix Message-ID: <1990Nov6.071459@ecn.purdue.edu> Date: 6 Nov 90 12:14:59 GMT Sender: news@ecn.purdue.edu (USENET news) Reply-To: cyliax@ecn.purdue.edu (Ingo Cyliax) Organization: Purdue University Engineering Computer Network Lines: 31 I have been thinking of a way to implement a paging Minix system that would not alter much in the MM process. Of course this would be a paging system and would require paging hardware as well as a MMU. Why not just implement a large virtual memory space for Minix and handle paging at very low level, in the kernel tasks for example. This way MM would just think it had a very large chunk of memory to work with. as it started to allocate memory chunks and the processes that started using them started page faulting the page task would page them in from disk, and page unused pages out to disk. The page task could tell the system task certain processes have to be suspended while their missing pages where paged in. Of course there has to be a way to protect the pages in the kernel tasks, as well as locking in pages during I/O. With this aproach there wouldn't be a need to change MM or FS. The changes would be confined to an additional task in the kernel and some minor changes in the system task, and possibly the drivers. All program would still run without change, except that you can chmem them as big as you need. Of course this doesn't help people that don't have architectures that do not support paging, but it would be very transparent. Unless I'm missing something. Comments ? -ingo -- /* Ingo Cyliax ECN, Electrical Engineering Bldg. * * cyliax@ecn.purdue.edu Purdue University, W. Lafayette,IN 47907 * * ing@cc.purdue.edu Work: (317) 494-9523 * * cyliax@pur-ee.UUCP Home: (317) 474-0031 */