Composite is a component-based OS that focuses on dependability and predictability. A functional system is constructed from a set of policies defined as components.

Why another OS?

1. There often exists a semantic gap between the policies and abstractions that applications desire from the system, and what the OS provides for them to use. This is especially evident in the embedded and real-time realm where correctness of the system is defined by temporal constraints; to construct a predictable system, tasks and interrupts might need to be scheduled in a very specific manner not provided by existent systems, thus the scheduling policies of the system do not match requirements of the system.
2. As systems become more complex, we as system designers, should be making application and OS construction easier. Web servers and programming language run-times should not be implementing their own schedulers: they should be able to reuse the tried and true scheduling code from the kernel. We need a repository of such policies so that applications can be created largely by composing these services.
3. Systems should be designed with dependability as a first-class concern. A fault in the file-system should not effect the networking subsystem, and a fault in a web-server's HTTP parser should not effect the static page handling subsystem. A mechanism for systematic pervasive reliability is absent in most systems, partially because this can have an adverse effect on performance and predictability.
4. Security should not be a second thought in modern systems. No application or plugin should be allowed to access abstractions or information that are not required to complete their goals. This principle of least privilege alone can prevent a multitude of security breaches.

How does Composite answer these challenges?

• Problems 1. and 2. are tackled by defining the policies and abstractions of the system in user-level components that are each isolated into their own protection domains. The components that the system is constructed from can be chosen specifically for the application that is executing. If the application requires a earliest-deadline first (EDF) dynamic priority scheduler, then a scheduling component can be chosen to be EDF. This ability to define system policies as specifically chosen components bridges the semantic gap. Additionally, specific components can be used anywhere in the system. The same scheduler component can be used as the main OS-level scheduler, and as a scheduler in a web-server. The system and applications are defined as a collection of components, and the same policies can be used in multiple positions in the system. A focus of Composite is to allow scheduling policies to be defined as components. This important policy has been difficult in the past to define at user-level due to a combination of controlling interrupt execution and scheduler synchronization. This is the topic of our RTSS'08 paper (below.)
• Dependability is a fundamental design goal of Composite. Components, by default, are executed at user-level in their own protection domains. Thus an error that manifests itself as a fault in some component cannot spread through errant memory manipulations to other components. This fault isolation is the basis for fault tolerance and dependability. A side-effect of protection boundaries between components is that inter-component communication (IPC, abbreviated traditionally as inter-process communication) can have significant computational overhead. A central feature of Composite is Mutable Protection Domains (MPD) that enable the dynamic reconfiguration of protection domain boundaries in the system. IPC Performance bottlenecks in the system are found and the protection boundary can be removed. All components that are not only the "critical path" of the system can be fully fault isolated, and only those that require performance are placed in the same protection domain. MPD makes the trade-off between performance and isolation explicit, and enables the system to dynamically adapt to system execution dynamics. In this way we wish to maximize the system's dependability while still meeting application performance and predictability constraints. MPD is the topic of the RTSS '07 paper, the '07 presentation, and the '08 poster.
• The IPC between components in the system is explicitly constrained by capabilities. A component, a, is only permitted to invoke another, b, if it has a capability to access b. This simple mechanism has a track record of providing safe systems through confinement and the principle of least privilege.

Composite is currently under development. If you have any questions, or would like the source-code, please feel free to contact me.