RAM disk vs paging + buffer cache

[Stuart D. Gathman]

In article <27300012 at convex>, watson at convex.UUCP writes:

> Conceptually, I agree that it would be nice if the file system buffer
> cache and paging system cache were one. You could have one set
> of kernel I/O routines, instead of two. You could dynamically
> use pages in the most optimal way, for file buffering, or text
> buffering. The problem is that you introduce serious coupling

The Mach kernel does exactly that!  Files can be simply memory mapped
and 'read' and 'write' emulated.  I am tremendously impressed by the little
I read in Unix Review concerning Mach/1 (partly because I had thought of
all the stuff except the network transparency and threads years ago
and couldn't get anyone interested in doing Unix 'right').  
Mach creates a machine dependent layer that handles 

	a) virtual memory
	b) tasks (like unix processes)
	c) threads (seperate CPU states within a task for closely
	   coupled parallel processing).
	d) ports (like SysV message queues with only one receiver.  Any
	   size message can be sent.  Big messages are handled by 
	   twiddling registers in the memory management hardware).
	e) device drivers

The only basic operations are 'send' and 'receive' to ports!  The messages
(although arbitrary from the kernels point of view) contain headers and
are typed so that data formats can be automatically translated when
required.  The ports in effect behave like objects in smalltalk.

Memory is logically copied (for forks, messages, etc.) via "copy on write".
The memory is simply mapped into a tasks address space as read only.
When a write is attempted, an actual copy is made.

'pagein' and 'pageout' ports can be specified when allocating memory.
This is how a file can be memory mapped and why programs don't have to
be 'loaded' in the unix sense (which effectively copies the program data
from the executable file to the swap area).

Ports can be attached to file systems, network servers, SysV emulators,
and whatever running in user state.  You can page your virtual memory
to a filesystem on a remote machine transparently!  The network acts
as one giant parallel machine.  (This is the part I didn't see before.)
The only non-transparent effect is that particular code and data will mean
different things to different processors.  (I.e. 68k code will not execute
as desired on a 286).  Because of the typing standard for messages, data
can be automatically translated by the server for a different CPU.  This
means setting up a file system on a seperate CPU is trivial!

This kernel is also more portable because the machine dependent portion
is so small.  To port your system (complete with SysV and Berkeley 
unix environments plus new parallel stuff), you need to change the compilers
code generator to handle the CPU, change the kernel to handle the memory
management, and change the device drivers to handle the I/O.  Unix stuff
like pipes, message queues, semaphores, sockets, streams, raw devices,
you name it, can be emulated _efficiently_ and portably using 'ports'.

These concepts require CPU's with

	a) large address spaces. (for memory mapped files, not strictly rqd)
	b) memory management with fault recovery. (for copy on write)

8-bits are out.
80286 would work, but segments complicate efficient code generation.
80386 is in.
68010, 68020 is in.
68000 is out (no page fault recovery).
S/1 is out (no page fault recovery).

The concepts in this system make the computer network envisioned in
'Tron' a practical reality.
-- 
Stuart D. Gathman	<..!seismo!{vrdxhq|dgis}!BMS-AT!stuart>