A Scalable, Compositional Operating-System |
Design of RMoX[ top-level | base-layers | kernel | driver-core ] This page gives some details on how RMoX is structured, and how its various components fit together. Top-level system structure
At the bottom of this is the hardware, i.e. the machine (or emulator) that RMoX runs on. Interacting directly with the hardware are RMoX's device-drivers and 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, SMP), access to physical memory, interrupts and IO/memory-mapped devices. The scheduler component is responsible for occam-pi process scheduling and communication in RMoX. At the moment, this is a slightly modified build of the CCSP run-time kernel used in KRoC. The device-drivers, mostly written in occam-pi, allow RMoX and its applications to use hardware devices (in the same way that device-drivers in other operating systems do). We currently have drivers for a variety of standard PC hardware devices, including keyboards, mice, USB host controllers, and the particular hardware found on our PC104+ systems (including a framebuffer driver for the AMD Geode GX, and a touchscreen input driver for the Philips UCB1400). On top of the device-drivers and scheduler sits the RMoX kernel proper. Described below, this is the process network that provides our operating-system functionality (including running applications). RMoX base-layersThe two base-layers currently supported are:
Three other base-layers that we have used previously, but are no longer supported, are:
Planned for the future are:
The RMoX kernel
The four core servers are:
The system 'startup' happens inside the console process. This is where initial device-drivers are loaded and started, and the ramdisk file-system mounted, before starting up the six virtual consoles (and processes that switch the keyboard and screen between them). The first virtual terminal is used for log-output, which is also dumped to a serial-port by default (specified in the RMoX configuration). The fifth and sixth virtual terminals run instances of the system-console process, into which a user can type commands, etc. The other three virtual terminals, if so configured, run demonstration animations (dining philosophers, bar simulation and matrix simulation), otherwise these are available for use. The function keys F1 - F6 can be used to switch between virtual terminals. Inside the driver-core
In fact, this is only part of the picture, as the "usb.hcd" driver will be connected to the "pci" driver (to get access to the PCI based USB host controller). The "usb.hcd" driver will also be connected to the "system" driver, to receive interrupts, as will the "i8042" driver (for keyboard and mouse interrupts). The "i8042" driver is also connected to the generic "pointer" driver, which like the "keyboard", can receive events from multiple sources. The "dnotify" driver is used to organise rendezvous between components. For instance, when the "usb.keyboard" driver is started, it establishes a connection to "dnotify", and requests to be notified of USB keyboard class devices as they become available. The "usb.driver" process network is also connected to "dnotify". When a new USB keyboard is connected to the system, "usb.driver" will send a notification message to "dnotify", which in turn notifies the "usb.keyboard" driver. On receipt of such a message, the "usb.keyboard" driver establishes one connection to the "usb.driver", to interact with the device (whose I/O traffic is scheduled on the USB bus managed by the "usb.driver"), and another connection to the generic "keyboard" driver, to which it sends keystrokes received from the USB device. In a similar fashion, the "i8042" driver also delivers keystrokes to the "keyboard" driver. As with typical operating systems, any keyboards plugged into the system become available for use on the system console. However, things don't have to be arranged this way: we can easily modify the system to deliver keystrokes from newly connected USB keyboards elsewhere. Outside of the driver core, keystrokes are passed up to the "console" process, which intercepts F1 through F6 for switching between virtual terminals, and passes any other keystrokes to the particular process running in those terminals (e.g. the "system.console"). Only six driver processes are shown above, and then, only at the outermost level — most of the device drivers are implemented as process networks. An actual up and running system may have in excess of 30 top-level drivers, with hundreds of processes running inside these. The resulting connections established dynamically throughout the system can become complicated (to look at), but are not complex: like the overall system, these construct their own client-server (or IO-PAR) process networks, which we can reason about formally, and for which we can have guarantees of deadlock and livelock freedom. The technicalities of actually doing this are under construction (requiring CSP-based compiler analysis of occam-pi code). In essense, specifications for process interactions are developed, with which the compiler can ensure correct implementation, and which we (with the help of proof tools) can use to reason about the compositional correctness of these interaction specifications. |
The diagram on the right shows the top-level structure of the RMoX system:
The diagram on the right shows the top-level process network for RMoX. Most of the system's code and functionality is contained within the
four core server processes. The kernel process acts largely as a switch, redirecting requests from the console and elsewhere to the
appropriate server.
The diagram on the right shows a selection of the internals of the driver-core process network, specifically those that handle keyboard input in some fashion.
