🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.os.mach
Article #1093

Re: General discription of Mach

#1093
From: Phil Howard KA9WGN
Date: Tue, 14 May 1991 06:11
48 lines
3019 bytes
mrt@MRT.MACH.CS.CMU.EDU (Mary Thompson) writes:

>central to its design. If you are talking about Mach 3.0 then it depends
>on what sort of servers you have running and what functions they support.
>At the moment most Mach 3.0 servers are still in the implementation or
>early testing phase.

Actually I was thinking both of 2.5 and 3.0.

For 2.5 I was not sure how the BSD calls were actually implemented.
I assume in 3.0, BSD calls would just be a library that exchanged
messages on port(s) to the BSD server(s).

What remains of an interest is how the servers themselves (which I
assume even in 3.0 will run in their own tasks) do the actual I/O
once requested from some other task.  Obviously there would need to
be some protection and/or assignment mechanism that the servers would
take advantage of to get access to the I/O devices and yet prevent
ordinary tasks from doing so.

Where would server's binary code be "loaded" from, or would they really
be linked in with the kernel, but just run as tasks?

Where would I/O device drivers be?  What I originally heard of MACH a
few years ago suggested that it was a system that allowed a UNIX kernel
to be written in a multitasking way.  Seems like this will be so at least
in 3.0.  I had made some mental assumptions at the time, such as that
MACH would be a different kind of thing than it really is.  Particularly
I suspected it might be a multitasking system that ran strictly in the
real address space that enabled a conventional kernel to create the
virtual address spaces with the advantage of a multitasking base to run
on.  Believe this I looked forward to the idea of device drivers getting
access to the same benefit.

I suppose I will be curious what is "under the hood" in MACH, and look
forward to a more public 3.0 source availability.  Particularly I am
curious if there is an underlying multitasking system of sorts, such as
perhaps one special "task" that represents the real address space, and
multiple threads within it just as much as any task can have threads.

Part of the curiosity is to compare with a small system I am designing
and writing now.  It does not have any virtual memory facilities at all,
nor a file system, which should give you an idea how "low" it really is.
-- 
 /***************************************************************************\
/ Phil Howard -- KA9WGN -- phil@ux1.cso.uiuc.edu   |  Guns don't aim guns at  \
\ Lietuva laisva -- Brivu Latviju -- Eesti vabaks  |  people; CRIMINALS do!!  /
 \***************************************************************************/
Technical Details
Message-ID: <1991May14.061156.29760@ux1.cso.uiuc.edu>
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!phil
References: <1991May13.174717.14031@cs.cmu.edu>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!rpi!uwm.edu!ux1.cso.uiuc.edu!phil
From: phil@ux1.cso.uiuc.edu (Phil Howard KA9WGN)
Newsgroups: comp.os.mach
Subject: Re: General discription of Mach
Message-ID: <1991May14.061156.29760@ux1.cso.uiuc.edu>
Date: 14 May 91 06:11:56 GMT
References: <1991May13.174717.14031@cs.cmu.edu>
Organization: University of Illinois at Urbana
Lines: 48