Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!mips!apple!well!aleks
From: aleks@well.sf.ca.us (Brian J. Witt)
Newsgroups: comp.os.mach
Subject: Re: Mach Underground newletter
Summary: Pure-Mach
Keywords: Mach status, memory requirements
Message-ID: <16490@well.sf.ca.us>
Date: 3 Mar 90 06:02:10 GMT
References: <8226@pt.cs.cmu.edu>
Reply-To: aleks@well.UUCP (Brian J. Witt)
Organization: Whole Earth 'Lectronic Link, Sausalito, CA
Lines: 38

In article <8226@pt.cs.cmu.edu> mrt@mrt.mach.cs.cmu.edu (Mary Thompson) writes:
>This news bulletin is an attempt to answer some of the frequently
>asked questions about Mach and to provide updates on the current
>status of our releases and research. 

Great!!!  ^G^G^G^G  Let's keep the fact flowing!

>Mach 3.0
>------------
>
>Mach 3.0 is the pure Mach kernel (without Unix compatibility support)
>which will be available without requiring external licenses.
>This kernel has been running at CMU for over a year and is now up on 
>Vax, Sun 3 and PMAX platforms.
 [..]
>Device drivers for most machines would also require licenses from
>the appropriate manufacturers. 

My understanding (a fact untested) is that "pure Mach" means a 
machine independent virtual memory manager and message passing
mechanism.  I'm curious how much memory (real and paged) just this
much of Pure-Mach requires.  Perhaps a number not counting and
disk paging code (Pure-Mach).  Can you beat 90K?

  I'm just wondering if the Mach builders, or researchers with Mach,
might enter the parallel processor biz.  Shared memory might be the
next direction.  Instead of explicitly communicating results one
message after another, a process would just give up a segment of memory to
another node to work on.  This segment could hold a column of data...

   BTW, I'm very impressed with your 'paging' benchmarks against
real-live bsd and Unix(tm) boxes.  But using a 26meg VAX for running
your tests if quite.. quite.. quite.. WiLd ! 8-()


---- "Sometimes doctor, I wake up and don't know who I am..."
                     -- confessions of an abstract data type
---- brian witt              USENET:  aleks@well.sf.ca.us