Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!ncar!gatech!udel!mmdf From: tsarna@polar.bowdoin.edu (Tyler Sarna) Newsgroups: comp.os.minix Subject: Re: Virtual addresses Message-ID: <53831@nigel.ee.udel.edu> Date: 16 May 91 21:48:28 GMT Sender: mmdf@ee.udel.edu Lines: 65 Peter Holzer writes: > tsarna@polar.bowdoin.edu (Tyler Sarna) writes: > >CvW writes: > > >> How it is done in practise is under discussion. Opinions go from > >> - integrating MM in the kernel > >> to > >> - leaving MM as it is, but expanding the MM-Kernel interface. > > >I vote for #2. > > I vote for #1. As far as I can see, MM does very little without aid by > the kernel, so making separating it from the kernel makes things more > complicated, not easier. (Maybe the 64k segment limit of the 8086 was > the reason to separate it from kernel, I don't know the sizes offhand) > Process control should go into the kernel, IMHO. (I guess, I will get a > lot of flames for this) Yes, but this is such a major change that the resultant system would barely be minix anymore, and any possibility of upgrading to a new version of Minix (say 2.0) would be virtually nil. Not that the whole venture itself doesn't imply many, many changes, but the number should be kept as low as possible. > >> most likely, the kernel uses a 'flat' address space. > > >FS and MM can be flat too. It might be easier. > > They are not flat now on 80x86 Minix. I see no reason to introduce such > a big conceptual difference between PC-Minix and Atari-Minix. Who said Atari? This applies to any 68k minix (sorry, pet peeve). This is not "introducing", so much as keeping things the way they are now. > >One thing I'd like is the ability for processes to expand so > >that when a process grows past it's chmem'd limit, it just gets > >bigger. This could be done with swapping. > > This won't work because the Stack grows downward from the chmem'ed > address. When stack and heap meet, you cannot just expand your > data/stack segment and copy the stack to its new location without > invalidating all pointers pointing into the stack area (e.g. argv). Sure it will work. If things not being in the same place in memory was in insurmountable problem, we wouldn't now be talking about virtual addreses, would we? The MMU can be used to map the bottom of the data segment right after the code segment, and the top of the segment at the top of the virtual address space. If the stack of data space needs to grow, we simply move the stack space up in real memory. The mapping takes care of everything. > But, most programs only use limited stack space but want to malloc lots > of data. So you could reserve a limited area at the _beginning_ of the Look at the GNU tools. They allocate massive amounts of space on the stack with alloca. At any rate, it looks doable to me. -- Tyler "Ty" Sarna tsarna@polar.bowdoin.edu "Navy. It's not just a job, it's $98.76 a week." -SNL