Newsgroups: comp.os.minix
Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!email!vmars!hp
From: hp@vmars.tuwien.ac.at (Peter Holzer)
Subject: Re: Virtual addresses
Message-ID: <1991May16.171429.438@email.tuwien.ac.at>
Sender: news@email.tuwien.ac.at
Nntp-Posting-Host: gipsy.vmars.tuwien.ac.at
Organization: Technical University of Vienna
References: <53697@nigel.ee.udel.edu>
Date: Thu, 16 May 1991 17:14:29 GMT
Lines: 58

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)

In fact I don't really like the Minix Servers. They have to know much
too much about processes to work properly. If a process forks or exits
all servers need to know about this (This is not a problem now, because
there are only two, and one of them (MM) is responsible for this type
of events anyway, but consider a system which has many servers (FS, MM,
remoteFS, some graphics server, ...)

>> Surely, FS and MM will have their own address space like every other process,
>> 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.

>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). 

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
data space for the stack and the heap can grow to the end of RAM.

Of course what I really would like is a MMU that uses signed addresses
and both an upper and a lower bound of the segment.
The heap grows into the positive area and the stack into the negative.
You can simulate this with MMUs that fit segment+offset into 32 bit by
using segment 0 for data and segment ((unsigned) -1 % (NO_OF_SEGS) 
for the stack or by paging.

--
|    _  | Peter J. Holzer                       | Think of it   |
| |_|_) | Technical University Vienna           | as evolution  |
| | |   | Dept. for Real-Time Systems           | in action!    |
| __/   | hp@vmars.tuwien.ac.at                 |     Tony Rand |