[comp.os.minix] Thoughts on the MINIX Memory Model and merging sources

cagney@chook.ua.oz (Andrew Cagney - aka Noid) (09/25/89)

These ramblings first look at a particular problem of the MM process
and its portablity, and then give a general 'rave on the higher aims
of the minix developer :-)'


I've been looking through the MM code to see how 'difficult' it's going to
be to upgrade an NS32000 version of MINIX to v1.4b. In the MM process the only
striking difference is all of the 
	#ifdef ATARI_ST
lines. (There are other changes but they are not relevant here.)

From memory these $ifdefs are due to the ATARI_ST not having any memory
management hardware, and not simply because it's an atari machine. Following
this thought through, the machintosh (unless you are very rich) also does not
have any memory support, so again has this problem. So perhaps the 
ATARI_ST's in the MM should be replaced by HW_MMU (or HW_NO_MMU).
(Before you flame me, my definition if MMU is very loose).

Following this on any port to hardware with out a mmu only needs to ensure
that MM_HAS_MMU is not defined and hopefully the PC sources for the MM
process can be used.

Sounds good in theory let's have a more careful look.

First a look at what hardware supplies for memory management.
(this is a simple summary of what you find in any good os book)

1. No memory management (e.g. ATARI ST, COMMODORE 64, MACINTOSH et al.)
=======================

On this hardware there is no way possible to relocate a task data
area. In particular true pointers (not Mac ones) can not be moved as they are
absolute physical memory addresses. Consequently once a task data
area is placed in a certain area of memory it *can*not* be moved.
When it comes to forking a task you get the problem of two tasks
wanting to have their separate data area's at the same memory location.

In ATARI minix, to get around this problem, exchanging of memory occurrs.
Putting it simply, before a task is run, physical memory may need to be
shuffled so that the tasks data area is located where it should be. 

This is why the MM has these ifdef ATARI_ST

2. Simple base and bound (e.g. 8088 The original CYBER et al.)
========================

This hardware get's around the problem of absolute addresses by providing
a base register for a task. Any memory access made is relative to that
register and not an absolute physical address. Consequently should a task
need to have its data area moved then only the base register need be set
to the new location of the tasks data. The i8088 is an example of a 
variation on this theme. Instead of one memory area it has three.

Some versions of this even support memory protection in that attempts to
access memory outside of the bound can be detected.

Unfortunately this sort of memory management requires a process to have
physically contiguous memory.

3. Page systems (e.g. NS32000, VAX, TANDY COLOR COMPUTER (true :-) et.al.)
===============

[Notice page not paging :-)] Simply a page system allows a tasks address
space to be build up of non contiguous evenly sized pieces of memory.

Some page hardware even allows you to control what access can be made
to each page.


To summarize we have the following broad definitions:

1.	NO Memory Management support
2.	BASE&BOUND Type memory management support
2a.	B&B MM support with memory protection
3.	Page Memory management
3a	Page Memory management support with Single page protection.
[Other	:-) If you think  I've mised a memory model that does not fall
	into one of these groups then mail it to me]

[One example of memory hardware I have missed is that extended memory found
on some pc's. Any thoughts on that one ?]

B. What minix requires to run
=============================

Using the ATARI implementation of minix no memory management hardware is 
needed. I'd expect ATARI uses to agree, however, that the memory swapping
makes this version a little inefficient.

The current alternative (PC minix) makes use of a base and bound memory
model (those segment registers). 

Bruce Evans Protected Mode 286 MINIX adds to this, memory protection.

Continuing further up the ladder John Vaudin's NS32000 port makes
use of the NS32000 pages but only takes a simple approach. The
NS MMU is made to behave similar to the the Memory manager in Bruces
Protected Mode minix.

Finally at the other extreme of implementations there is Bruce Culbertsons
NS32000 version. He's used the ability to individually protect pages of memory
(a fork using copy on write) in his implementation. A task impossible for
the ATARI :-).

C. Consolidation
================

Above I've listed what I hope to be a reasonable summary of several different
classes of Memory Mangement and correspondingly version of minix that runs
on each. Following this on I propose the following classes for minix memory
management hardware.

	1. HW_MMU	If this is defined then the hardware is able to
			support some form of base and bound.

	2. HW_MMU_PROTECTION
			This means that the MMU hardware can detect at least
			at task attempting (a) in the following:
				a) Task accessing an address outside
				   of its address space
				b) Attempts to modify the tasks
				   text area. (1)

	............................

	3. HW_MMU_PAGES
			This means that the memory manager is able to
			allocate memory to a tasks using non contiguous
			chunks (with in a segment).

	4. HW_MMU_PAGE_PROTECTION
			This means that the hardware is able to detect
			the events in 2 but to the level of a single chunk.

So looking at the implementations of MINIX:
The atari would have nothing defined (maybe HW_NO_MMU). While for Bruce C's
NS32000 implementation every thing would be defined.


4. Extension
============

MINIX at present is being ported to a plethora of machines. Not just
variations of the PC but to completely different hardware. This is
creating a diverse and overwhelming collection of different minix versions.
Unfortunately, as has been highlighted by the ATARI, the different
implementations are missing out on updates/upgrades that apply to the PC
core version. AST has rightly stated he is *not* going to support an infinite
number of different versions of minix (not even MINIX-CRAY:-) so some other
solution to the problem upgrades to minix is needed.

Rather than support the different versions, I suggest that PC minix should
be made more open. Making it easy to 'hook in' the key routines for different
architectures instead of the present situation of tweaking things every
where. The scattering of HW/machine specific code in the MM & FS should
be shifted to the kernel. And where the shift is not possible, i suggest that
generic definitions rather then specific references to hardware be used.

For example I suggest that in the Minix MM process, HW_MMU be used rather then
ATARI, i8088 etc. People porting minix to more advanced hardware could
correspondingly in their LOCAL versions of minix add #ifdefs according to
the third and fourth clasifications. I intend doing this.

Further there be a real push from both the PC and the ATARI side to flush out
as many conditional code segments in the MM & FS as possible. A good example
its rumored, is in the v1.4b (shhhh) mm/alloc.c file. The kernel now tells the
mm where the different parts of memory are. Previously the MM process new
all about the innards of the machines memory.

Crash arrrrrrrrrrrrrrrrrrrrrrrrrrrg splat
I think the soap box just broke.

					Comments ?
						Andrew Cagney


-------------------
(1)	This is deliberately vague. If a processor has a really simple
	base and bound support (forcing common I&D&S) Then every thing
	must be put in the data area. Consequently, no text area exists,
	so any write to it is always detected.  :-)

pcf@galadriel.bt.co.uk (Pete French) (09/28/89)

From article <599@augean.OZ>, by cagney@chook.ua.oz (Andrew Cagney - aka Noid):
> 
> 1. No memory management (e.g. ATARI ST, COMMODORE 64, MACINTOSH et al.)
> =======================
> 
Commodore 64 - you have got to be kidding ! We considered a port to the BBC
micro, but it required lots of sideways ram for switching, woould have to swap
to disk and wwould cerainly not run on a basic machine.

If you can port Minix to a 64K 6502 machine I will be most impressed.

-Pete.

-- 
       -Pete French.               | "I'm just a vision on your TV screen,
  British Telecom Research Labs.   |  Just something conjoured from a dream"
 Martlesham Heath, East Anglia.    |
All my own thoughts (of course)    |                       -SIOUXSIE.