1. Intro

The Mach Multiserver (Mach-US) is an operating system developed as part of
the CMU Mach project. Work on the multiserver has been conducted both by
members of the
CMU Mach project and by members of the OSF-RI.

The current version of Mach-US supplies a Mach2.5/4.3BSD API and runs most
non-administrative UNIX applications. No re-compilation is required.

2. Quick System Architecture Overview

Mach-US is referred to as a symmetric multi-server system. It has a
set of separate servers supplying generalized system services (file
systems, network server, process-mgr, tty server,...) and an emulation
library loaded into each user process. This library uses the services
to generate the semantics of an industry standard OS being emulated.
Some of the system servers are, in part or whole, specific to the OS
being emulated while most are meant to be fully generic. Thought was
given when writing the OS specific ones to make parts of them reusable
for other OS's. There is no "central" server, either for emulating a
specific OS or for general traffic control. All multi-service actions
are controlled by the emulation library.

3. Mach-US Flexibility

The biggest single advantage of Mach-US is its flexibility. It offers
a whole new, highly modifiable OS architecture without significant
structural impediments to speed.

3.1 Object-Oriented Generic OS Interfaces

Several sets of C++ based object-oriented interfaces (virtual
classes/methods for multiple inheritance) define semantics
supplied by the system servers. These interfaces are: access
mediation, naming, I/O, net_control(OSI-XTI based), and async
notification. The various servers then support a combination of these
interfaces to do their work and an emulation library uses them to
emulate the target OS in question.

This uniformity of access makes it easy for new servers to supply
additional functionality by sliding into the name-space under the
known interfaces. Then that functionality is generally available to
the system users through their pre-existing software (for example, "ls
/servers/net/TCP" will tell you about active TCP sockets/connections).

Since the iterfaces are object-oriented it is simple to make refinements
of them via inheritance.

3.2 Modular Services

Different functionality is separated into various servers:
configuration, authentication, pathname, diagnostic, pipenet, ufs,
process-mgr, tty, and network (with a University of Arizona xKernel
protocol engine). This separation makes makes it simpler to develop
and debug OS services. One can also add and subtract services as
needed for a given invocation of the system. Furthermore, a bug in
one service doesn't crash or corrupt the entire system.

3.3 Object Library/Code Reuse

There is an extensive object library both for the support
of the generic interfaces as well as specific classes to implement
general server building
blocks.
Some of the functions that are provided are: client-server binding,
name-space manipulation, mapped-files/shared-memory/page-objects, IO/bulk-data
and protection. These classes enable faster prototyping of a new server and
ease creation of servers from foreign code.

Two common cases of considerable complexity are handled by the following
packages of interface and implemenation classes and macros:

Remote Method Invocation: The remote method invocation system
enables clients of the system services to simply invoke a method
against an OS Item. The appropriate method is correctly invoked on
the appropriate server. This occurs with the needed authentication
and protection guarantees.

Interrupts/Signals: This package enables server code to handle
interrupts and UNIX signals in a consistent and relatively painless
fashion. The remote invocation system handles informing a server when
a invocation should be interrupted. The macros and routines provided
by the interrupt package can be placed in the server and emulation
code at points where they can enable interrupts to be handled
punctually, correctly and atomically. This package has been used to
port previously interrupt ignorant code into a server that responds
correctly to UNIX signals. The portion of the interrupt system that
the servers use is not specific to UNIX signals but works for any
source of interrupts (pending invocation cancelations). Most of the
emulation_lib side of this mechanism is either OS independent, or
easily modifiable for a different signaling semantic.

4. What is the Mach-US status

4.1 Current functionality: What's running

Self Hosting: Mach-US has been used to build itself.

Test Software Development: It is used as the default platform for
development of test software used to test Mach-US functionality.

Andrew Benchmark: Runs.

Parallel Compile Test: There is a version of the standard Mach
compile-test (which just compiles a number of small programs)
that runs many compile tests at the same time. Mach-US runs this test
with heavy loads on uni-processor and shared memory multi-processor
boxes.

Day to day tools: Most of the common UNIX utilities we know and
love (csh, vi, gnu-emacs, find, ...) are working without problems.

FTP(d)/Telnet(d)/Inetd: Are used regularly.

4.2 Current Reliability

Positive:

Runs and works: One can log into this Unix system and do useful
work today. Typing at a cshell, one has full tty and job control,
pipes and signals, file access and access control. It is very much a
real UNIX.

Stays up indefinitely: There is no noticeable system rot. It
does not crash in the night, or during average use.

Handles heavy computation stress: The system has been stressed by
various tests, self-hosting, and general use. It handles the
stress well.

Negative:

First time applications uncover bugs: When a large new bit of
software runs, it may uncover either a bug or a small missing
feature/esoteric semantic.

Untried code paths: There is some code or odd interface features,
that have never been used and hence may not work.

Different error values: Mach-US may return a different error or
errno than Mach2.5 would have for the same error.

4.3 Speed

In general the CMU Mach single-server(Mach-UX) runs %10-%20 faster
than Mach-US for common usage tests. Yet in a highly parallel task
(parallel compile test) on our multi-processor Sequent box, Mach-US
performs slightly better than Mach-UX. It has also been measured to
run much faster than Mach-UX for FTP.

Because of the sophistication of our emulation library, most syscalls
(as defined by occurrence during test) do not make any calls to the
servers, but instead are handled in the client process. By this
property, it should be possible that Mach-US could be made to
run faster than the
Mach-UX system in general. Furthermore, with the exception of remote
method invocation, we have yet to find the time to meter it heavily to
discover what slowdowns exist. Simple changes alone, driven by such
metering, should make the system as fast or faster than Mach-UX.

Yet, there are other obvious places for speedup: bundling common
server call sequences, shared libraries for server text, optimizing
forking and signaling, and optimizing out some debugging mechanisms.

5. Release/Distribution

Mach-US is distributed via "SUP" to several sites at this time, and
is available to OS researchers. To get a fully functional system a
site must have a Mach 3.0
license and the prerequiste 4.3BSD license.

There is also a license-free release available. It is missing the sections of
the ufs and tty servers that are derived from BSD code as well as parts of the
libmach3 library that are derived from libc.a. While this release of the code
will not support UNIX applications, it is available for study or reuse. The
object-interface library, the remote invocation method and the interrupt
handling package including the task master server may be of real value to
designers of other object-oriented distributed systems. A compresed tar file
of these files can be FTP'ed from public/src/mach_us/mach_us.tar.Z (4.3M).
Click
here
only after you have set your browser to load to disk.