What is the Mach Multiserver?

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.

OS specific services (like the process-mgr), may supply specific interfaces within the same basic C++ virtual class model.

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:

4. What is the Mach-US status

4.1 Current functionality: What's running

4.2 Current Reliability

Positive:

Negative:

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.

For details on SUP'ing and running the Mach-US system see the note Installing and Running Mach-US.

J. Mark Stevenson, Senior Research Programmer. jms@cs.cmu.edu


Top Top
grm@cs.cmu.edu