A Scalable, Compositional Operating-System |
| [ Main | Documentation | Papers | Download | Building | Links ] |
[ intro | news | authors | mailing-list | overview | structure ]
Introduction
RMoX is an experimental/research occam-pi/CSP based operating-system for (currently) Pentium based PCs. Our motivation for this is driven by the need for reliable, scalable and robust operating-system environments. CSP provides a solid foundation for describing and reasoning about parallel systems and their interactions. The occam-pi language is an enhanced version of occam (based on CSP), that adds ideas from the pi-calculus to provide a dynamic and flexible environment for building such concurrent systems.
Development work on RMoX is currently funded by EPSRC (UK research council), as part of grant EP/D061822/1. This is primarily for developing RMoX on PC/104 embedded PC systems.
Traditional occam was designed for Transputers (as developed by Inmos Ltd. and later SGS Thompson, now ST Microelectronics), which had a very finite memory, and no provision for features such as virtual memory (although the T9000 did provide a limited form of fault/memory protection). Transputers were primarily targetted at embedded-systems and therefore the use of such features would have been limited (especially considering the silicon cost).
The use of occam on modern computing systems has motivated substantial language development -- both at the language level and in the capabilities of the run-time system. As a result, occam-pi now provides support for facilities such as: data, channel and process mobility; multi-level process priority; extended synchronisation; and numerous other features. More information on occam-pi can be found here: http://occam-pi.org/.
Whilst occam-pi is sufficient to develop many components of an operating-system, some of the more architecture-specific low-level operations remain tricky (and perhaps not best done in occam-pi). RMoX contains various "base-layers", one is selected depending on how you wish to use RMoX (e.g. user-mode in the host OS, or standalone). The various base layers are described below.
News
- 14/07/2007 various web-page updates
- 13/07/2007 wiki operational at http://rmox.org/wiki/
- 13/11/2005 updated web-pages and moved to top-level
- 17/01/2005 updated for KRoC/Linux 1.3.4-pre4
- 10/01/2005 updated for RMoX-0.1.3 and KRoC/Linux 1.3.4-pre3
Authors
RMoX is currently being developed by Fred Barnes, Carl Ritson, Peter Welch, Adam Sampson and Brian Vinter. Fred Barnes and Peter Welch work at the University of Kent, UK, in the Department of Computer Science, where Adam Sampson is a research-student and Carl Ritson a research-associate. Brian Vinter works for the University of Copenhagen, Department of Computer Science.
We are also grateful to the following people, who have provided ideas, inspiration, and who have endured our (sometimes lengthy) technical discussions or contributed in other ways (in no particular order): Dyke Stiles, Jim Woodcock, Alister McEwan, Andrew Butterfield, Mario Schweigler, David Wood, Matt Pedersen, Joe Sheridan, Ruth Ivimey-Cook, Roger Peel, David Reeve, Phill Camp, Ramsay Taylor, and the The WoTUG/CPA Community.
Mailing-list
RMoX has the following mailing-lists:
- rmox-dev: general development list
- rmox-announce: announcements
Overview
The following diagram shows the run-time structure of the RMoX system:
Any hardware interaction is performed either by RMoX's device-drivers or the "base-layer". The base-layer provides an abstract interface to the hardware and can be changed depending on the desired use of RMoX. The main functions of the base-layer are to provide the bootstrap, discovery and initialisation of certain hardware (e.g. the MMU), access to physical memory, interrupts and IO/memory-mapped devices. The various base-layers are:
Raw base-layer: this is now the default base-layer, written in a small amount of assembler and C, performing basic initialisation and providing support functions for the run-time system.
User-mode base-layer: this provides a hardware abstraction for running RMoX in an existing Linux system as a normal user-mode application. This approach is particularly useful for debugging high-level functionality.
Minlinux base-layer: this is a stripped-down version of the Linux kernel (2.4 series) that essentially replaces the traditional "init" task with the RMoX system. This replaces the Flux OSKit used previously.
Linux26 base-layer: this is a minimal configuration and wrappers for Linux 2.6, that loads the RMoX system as a module when booted (unconditionally transferring control to it). This approach is slightly cleaner than the minlinux base-layer as it does not require any modifications to the Linux 2.6 kernel tree.
The run-time KRoC/CCSP kernel provides the scheduling and communication routines for occam-pi processes. This is essentially the same run-time kernel as used in KRoC/Linux, called CCSP. The version of CCSP currently in use is from pre-releases of the next KRoC/Linux version (1.4.1). Although the RMoX and "normal" versions of CCSP are built from the same source tree, what actually gets compiled is quite different (if RMoX is being built for non-user-mode; user-mode RMoX will get the standard KRoC run-time system).
The two Linux base-layers are now largely deprecated, as the raw base layer provides adequate functionality now (including debugging support). A planned future base-layer will be for Xen, allowing RMoX to run alongside other Xen-ported systems (primarily Linux, Windows-XP and Plan9).
Structure
The following diagram shows a possible arrangement of occam-pi processes, forming an active RMoX system:
Much of the system's functionality is provided by three `core' processes -- device-drivers (`driver.core'), file-systems (`fs.core') and networking (`network.core'). The system startup happens in the `console' process. This involves loading some initial device-drivers and the ramdisk file-system, before starting the various processes shown at the bottom-left of the diagram.
Access to the system is currently provided by the `system.console' process, that acts as a sort of built-in shell -- as there is currently no provision for loading and executing programs. Global access to the system is provided by the `kernel' process, that controls and mandates access to each of the `core' process networks.
The above diagram is currently slightly wishful, as many of the device-drivers shown are either unimplemented or incomplete. A basic working set of drivers is present, however. This includes a functional serial-port device-driver, on which a `system.console' process can be run.
