Adeos provides a flexible environment for sharing hardware resources among multiple operating systems, or among multiple instances of one OS, thereby enabling multiple prioritized domains to exist simultaneously on the same hardware.
Adeos has been successfully inserted beneath the Linux kernel, opening a range of possibilities, such as symmetric multiprocessing (SMP) clustering, more efficient virtualization, patchless kernel debugging, and real-time computing (RT) systems for Linux.
Unusually among HALs, Adeos can be loaded as a Linux loadable kernel module to allow another OS to run along with it. Adeos was developed in the context of real-time application interface (RTAI) to modularize it and separate the HAL from the real-time kernel.
Prior work
Two categories of methods exist to enable multiple operating systems to run on the same system. The first is simulation-based and provides a virtual environment for which to run additional operating systems. The second suggests the use of a nanokernel layer to enable hardware sharing.[1]
In the simulation category, there are tools such as Xen, VMware, Virtual PC and SimOS. There is also Kernel-based Virtual Machine (KVM) which is more similar to Adeos[citation needed], but is not RT and requires specific virtualization hardware support. These methods are used for users who desire to run applications foreign to their base OS, they provide no control over the base OS to the user. Simulation was never meant to be used in a production environment. In the nanokernel category there are tools such as SPACE, cache kernel and Exokernel. All of these suggest building miniature hardware management facilities which can thereafter be used to build production operating systems[citation needed]. The problem of this approach is that it does not address the issue of extant operating systems and their user base.[1]
Adeos addresses the requirements of both categories of application by providing a simple layer that is inserted under an unmodified running OS and thereafter provides the required primitives and mechanisms to allow multiple OSes to share the same hardware environment. Adeos does not attempt to impose any restrictions on the hardware’s use, by the different OSes, more than is necessary for Adeos’ own operation. Instead, such restriction is to be imposed by the system administrator or the system programmer. This exposes the system to mismanagement, but the idea behind Adeos is to give back control to system administrators and programmers.[1]
Architecture
Adeos architecture.
Adeos implements a queue of signals. Each time that a peripheral sends a signal, the different operating systems that are running in the machine are awakened, in turn, and must decide if they will accept (handle), ignore, discard, or terminate the signal. Signals not handled (or discarded) by an OS are passed to the next OS in the chain. Signals that are terminated are not propagated to latter stages.[1]
As Adeos has to ensure equal and trusted access to the hardware, it takes control of some hardware commands issued by the different OSes; but, it also must not intrude too much on the different OSes’ normal behavior. Each OS is encompassed in a domain over which it has total control. This domain may include a private address space and software abstractions such as process, virtual memory, file-systems, etc. Adeos does not attempt to impose any policy of use of the hardware except as needed for its operation. The task of determining policy is left to the system architect.[1]
Adeos uses an interruptpipe to propagate interrupts through the different domains running on the hardware. As some domains may prefer to be the first to receive hardware interrupts, Adeos provides a mechanism for domains to have access to priority interrupt dispatching. In effect, Adeos places the requesting domain's interrupt handler and accompanying tables, which may be called as an interrupt mechanism in SPACE terminology, at the first stages of the interrupt pipeline. Domains can control whether they accept, ignore, discard or terminate interrupts. Each of these has a different effect and is controlled differently.[1]
Accepting interrupts is the normal state of a domain's interrupt mechanism. When Adeos encounters a domain that is accepting interrupts it summons its interrupt handler after having set the required CPU environment and stack content for the interrupt handler to operate correctly. The OS then may decide to operate any number of operations including task scheduling. Once the OS is done, the pipeline proceeds as planned by propagating interrupts down the pipeline.[1]
When an OS in a domain does not want to be interrupted, for any reason, it asks Adeos to stall the stage its domain occupies in the interrupt pipeline. By doing so, interrupts go no further in the pipeline and are stalled at the stage occupied by the domain. When the OS is done wanting to be uninterrupted, it asks Adeos to install the pipeline and thereafter all the interrupts that were stalled at the corresponding stage follow their route to the other stages of the pipeline.[1]
When a domain is discarding interrupts, the interrupt passes over the stage occupied by the domain and continues onto the other stages. When a domain terminates interrupts then the interrupts that are terminated by it are not propagated to latter stages. Interrupt discarding and termination is only possible when the OS in a domain recognizes Adeos.
Since some OSes do not recognize Adeos, it is possible to create a domain which only serves as a handler for that OS. Hence, in the interrupt pipeline, this stage always precedes the handled domain's stage and may take actions for that domain with Adeos in order to provide the handled domain's OS with the illusion of normal system operation.
Once Adeos is done traversing the pipeline it checks if all domains are dormant. If that is the case, it then calls on its idle task. This task remains active until the occurrence of the next interrupt. If all the domains aren't dormant it restores the processor to the state it had prior the interrupt entering the pipeline and execution continues where it had left. Since Adeos is very much hardware dependent, many details are specific to one of its particular implementations.[1][3]
Applicability
General-purpose operating system resource sharing
General-purpose operating system resource sharing is one of the main objectives of Adeos, to provide an environment which enables multiple general purpose OSes to share the same hardware.[1]
Operating system development
Developing OSes is usually a complicated process which sometimes requires extra hardware such as in-circuit emulators to probe the hardware on which an OS is running. Using Adeos, OS development is eased since any undesired behavior may be controlled by an appropriate domain handler. It can also provide a default domain handler for OS development under which developers may have controlled direct access to the hardware they are meant to control. As Adeos is itself a kernel-module, such development domain handlers may be developed independently from Adeos.[1]
Patchless kernel debuggers and probers
Adeos provides for a way for kernel debuggers and probers to take control of Linux without modifying Linux. As with other Adeos domains, these facilities would load as normal kernel modules and would thereafter request a ring-zero domain from Adeos. Once that is done, they may request priority interrupt dispatching in the interrupt pipeline. Hence, before Linux gets to handle any interrupts, they will be able to intercept those interrupts and carry out the requested debugging tasks. This can also be extended to performance profilers and other such development tools.[1]
