Rex OS is being developed as an effort to explore the world of operating system design and implementation in the context of embedded real-time systems. An embedded system is a system that is placed into larger systemg such as automobiles, washing machines, and smart meters. A system is considered to be “real-time” if it is able to guarantee completion of tasks before a certain deadline. Therefore, an embedded real-time system is one that operates within a larger system and that guarantees completion of tasks by a specified deadline. In order to operate in such a restricted environment the operating system must be: reliable, efficient, and minimalistic. Rex OS is able to meet these requirements because it is based on a microkernel design which promotes these three characteristics.

There are three primary advantages to a microkernel design: small memory footprint, modular design, and increased reliability. The memory footprint of a microkernel is much less compared to that of a monolithic design. This is because the kernel only includes components that are critical to the system and tries to push all other components into user-space. In Rex OS even a critical component such as CPU scheduling is divided into two components such that only part of it resides in the kernel. As a result of pushing as many components into user-space as possible the system design has become extremely modular. The key benefit to this is that it allows the system to be modified for different uses simply by changing, or including, components in user-space. An example of this would be tuning the scheduler for different criteria. At the moment Rex OS is intended to be a real-time system; however, due to the modularity of the kernel and overall system it is trivial to take out the real-time scheduler and include one tuned for a multimedia centric system. Reliability in Rex OS is based on two key factors. First, due to the minimalistic nature of the kernel there is much less code running with a high privilege level which greatly reduces the chance for buggy code to cause the system to crash. Second, reliability is enforced as a result of all user-space tasks being isolated from each other.

Although there are many advantages to a microkernel design, it is not perfect. The primary disadvantage is that the system relies heavily on interprocess communication (IPC). This reliance is exemplified by the modular design of the system because the only way to communicate between tasks is to send messages through the kernel. This means that there will be overhead in the system necessary to facilitate these communications; however, this will be partially mitigated by providing system calls for a select set of kernel functions. It should also be noted that as a result of the modularity of the system, there should be minimal communication between tasks.

Figure 1: Layout of components in Rex OS

Figure 1 shows a diagram depicting the layout of Rex OS. From the figure it is clear that kernel aims to be as small as possible and that modularity is an extremely important concept in Rex OS.

Kernel-Space

The primary purpose of the kernel in Rex OS is to support tasks in user-space. As a result, the kernel is not permitted to implement any policy – it must only provide mechanisms for tasks to complete their job. This division of mechanism and policy is essential because it enforces a minimalistic kernel design and it promotes modularity within the system. Furthermore, it means that if a change in system behaviour is required in the future it can be achieved by modifying policies implemented in user-space as opposed to modifying kernel code.

The kernel provides support to tasks by:

• regulating access to system resources,
• marshaling communication between hardware and user-space tasks,
• providing an effective means of communication between tasks.

At an architectural level, the only component of a computer the CPU can access directly is main memory. All other I/O interactions are either routed through main memory or devices are accessed directly over the system bus. For this reason, the only two resources the kernel can regulate are main memory and the CPU itself. In order to facilitate communication with other devices the kernel must also provide a mechanism for communicating with hardware. This will be accomplished in Rex OS by utilizing memory mapped I/O as much as possible and providing port based I/O when necessary. Similarly, user-space tasks will need to be notified when certain hardware events occur so Rex OS must provide a mechanism for a task to register for hardware events. Finally, the kernel must provide a mechanism for tasks to communicate in user-space.

The components that make up kernel-space are:

• Dispatcher – provides a mechanism to perform a context switch between two tasks in the system.
• Memory Allocator – provides a mechanism to allocate and free memory.
• IPC – facilitates communication between tasks in the system.
• Device Marshaling – provides a mechanism to access hardware in the system.
• Interrupts – handles interrupts from hardware in the system.

With these components in place it is possible to build the user-space in Rex OS.

User Space

The only entity available in user-space is the task. Like other operating systems a task represents a unit of work in the operating system or, more accurately, a program in execution. The reason for such a strict design is that a task can incorporate other ideas, such as threads, but nothing else can incorporate a task. As seen in Figure 1 user-space in Rex OS is divided into three layers: L1, L2, and L3. The division of tasks between layers is such that a task can only request services from a layer below it. By doing this we enforce a clean design of the interfaces and acknowledge the fact that not all components may be present in the system at once.

L1 – The Kernel Object Layer
The lowest level in user-space is the kernel object layer. This layer contains tasks that have a corresponding object or mechanism in the kernel. For example, this is the layer where the scheduler would be placed because the kernel contains a corresponding mechanism (the dispatcher). Other components that reside is this layer are: virtual memory manager, task manager, and the resurrection daemon. Of these components the resurrection daemon is the only one that does not have a corresponding component or object in the kernel. However, due to the fact that one of the primary goals of Rex OS is reliability the resurrection daemon is included in this level.

L2 – The User Object Layer
The second layer in user-space contains tasks that represent objects a typical user would associate with a computer system. Of the components in this layer, special attention should be brought to the device drivers. Traditionally device drivers are included in the kernel because they require access to hardware and are potentially used by many components in the system. They have been pushed into user-space in Rex OS for two main reasons: reliability and decreased footprint. It has been shown that, of all traditional kernel code, device drivers contain the largest number of bugs. This is a direct result of the sheer number of devices supported and the size and complexity of some drivers. Furthermore, they are not included in L1 because they do not represent any object or mechanism present in the kernel as well as the fact that a user typically defines a computer based on the devices attached to it.

L3 – User Applications
The third layer in user-space is composed of user applications. This is the level that most tasks in the system will reside in. L3 is able to make use of services in L1 and L2 as well as the kernel itself.

Rex OS is designed to be reliable, efficient, and minimalistic. It aims to deliver a high degree of flexibility and extensibility while remaining clean and compact. The microkernel design of Rex OS allows us to achieve these goals by enforcing a small kernel and promoting an extremely modular design. Finally, Rex OS is an exercise in operating system design and implementation that will inevitably lead to a better understanding of how components within the operating system interact and will hopefully provide some insight into areas that can be improved for future technologies.