The Rambler Operating System Architecture

 

The following figure illustrates the architecture of the Rambler Operating System:

Figure 1. Rambler system architecture and components

 

This page is intended as a brief introduction to the Rambler architecture, which can be regarded as a kernel-less architecture since there is no traditional kernel part. As figure 1 shows, the HAL/IPC module, including the user-level portion and the kernel-level portion, is the only mandatory part common to all other software. Other kernel functions, such as interrupt dispatching, address space management, I/O permission management, and so on, are abstracted as processor devices. In other words, processor-specific functions are abstracted as processor devices. The concept of processor device implies that some processor-specific functions are allowed to work at user mode, depending on the processor architecture. User-level processor devices will result in good performance since no IPC invocation occurs. Another advantage of this concept is that the system becomes more flexible and tailorable with processor devices. OS designers can abstract more future processor-specific functions such as multimedia enhancement, distributed memory management, parallelism support, and so on, as processor devices and use a unified device manager to tailor/reconfigure the system. Based on this concept, the Rambler architecture is allowed to support a variety of processors, and evolve with the advance of computer architectures. Furthermore, a kernel-level plug-and-play mechanism is under design, which will allow the system to dynamically detect processor-specific functions and load the corresponding drivers.

 

In the Rambler architecture, address spaces are treated as short-term object containers called execution domains, some of which are the images of some long-term object containers. The concept of execution domain is like the concept of process, but has some differences: 1) A process is active, which must contain at least one execution unit like a thread. In contrast, an execution domain is passive, which is allowed to contain no execution unit until some events happen. 2) The address space of a process is usually flat, whereas that of an execution domain may be nested, i.e., tree-structured.

 

In the Rambler architecture, all kernel-mode components are put into a kernel-mode execution domain called Processor Domain. Besides the HAL/IPC module and some processor devices, Processor Domain contains some critical devices, which are some performance-sensitive devices not tolerating the overhead of context switching, or some devices that do not tolerate any failures.

 

Different from a traditional operating system like UNIX or Windows 2000 (TM), Rambler puts most devices into a user-mode domain, called Device Domain, for improving robustness. As the corresponding device drivers run in user-mode, these drivers are known as application-level device drivers. For protecting the address space of Device Domain and isolating failures, the Rambler architecture strongly recommends third-party hardware vendors to put their device drivers into some third-party device domains, as Figure 1 shows. If a third-party device driver corrupts, it only corrupts the related address space and any components relying on its functionality, but not the whole system. In contrast, the traditional operating systems may experience a total failure in this case, since there are many third-party device drivers running in kernel mode. The experience of L4 shows application-level device drivers are always helpful for improving robustness except when a hardware components permits system corruption (e.g., by physical memory access via DMA). In this case, "no kernel can prevent the driver from corrupting the system, and risk depends on the hardware accessible to the driver" []. For minimizing this kind of risk, current implementation of Rambler/i386 treats the DMA driver and the keyboard driver as critical device drivers, and put them into Processor Domain.

 

As Figure 1 shows, Service Domain plays a role of Windows NT executive []. This domain contains service modules shipped with the Rambler OS. Other third-party services are supposed to be put into some third-party execution domains for isolating failures.

 

One may notice that there is no thread module in Figure 1. In fact, the thread module is application-level and treated as a library linked into applications. Not like some user-level thread packages such as Threads [], Presto [], uSystem [], C Threads [], uC++ [], and Sun Lightweight Processes [], and so on, the Rambler thread library introduces system-level threads working at application level. Rambler achieves this goal by providing some primitives contained in a user-level HAL/IPC module, as Figure 1 show, for the thread library. Thus, the thread library can use these primitives to cooperate with the system for supporting synchronization and preemption. This approach not only keeps efficiency of user-level threads, but also avoids scheduling stalls as Scheduler Activations [] and First-Class User-Level Threads [] introduce.

 

The following sections expand on the roles of Processor Domain, Device Domain and Service Domain.

 

Processor Domain

 

Processor Domain contains the following major components:

 

Device Domain

 

Device Domain is a container of device drivers shipped with the Rambler OS. Third-party device drivers are supposed to be put into other domains.

 

 

Service Domain

 

Service Domain is a container of services shipped with the Rambler OS. Third-party services are supposed to be put into other domains.