As Adeos has to ensure equal and trusted access to the hardware it must take control of some hardware commands issued by the different OSes, but must not intrude too much on the different OSes' normal behavior. In order to achieve this fragile equilibrium the architecture presented in figure 1 has been adopted. It is a generalized form of the architecture presented in [7] and is not limited to providing what is referred to as portals in SPACE since it is also used to insure that every OS has a safe environment to operate in.
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 processes, virtual memory, file-systems, etc. As will be covered shortly, these resources do not have to be exclusive since OSes that recognize Adeos and are able to interact with it may be able to share resources with or access the resources of other domains.
Again, Adeos does not attempt to impose any policy on the usage of the hardware except as needed for its own survival. The task of determining policy is left to the system architect.In the type of environment provided by Adeos there are 4 broad categories of communication methods as illustrated in figure 1. Category A is a general usage of the hardware made by the different domains. This may involve any degree of memory access, hardware access and traps. Since successful memory and hardware accesses don't cause any faults, each domain operates as if Adeos wasn't present. Category B involves Adeos receiving control from the hardware because of a software or hardware interrupt (Adeos' interrupt management is discussed below). It also includes all hardware commands issued by Adeos to control the hardware. Category C involves invoking an OS's interrupt handler upon the occurrence of a trap while providing it the required information regarding the interrupt. If the domain is not aware of Adeos' presence, this may involve setting up the stack to resemble what the OS's interrupt handler expects. Category D involves two-way communication between a domain and Adeos. This is only possible if the OS in the domain is aware of Adeos' presence. This type of communication provides for maximum usage of Adeos' capabilities as it can be asked by a domain OS to grant it complete or partial access to resources belonging to other domains or even to grant it priority over other domains during interrupt handling. This may be used to provide cross-domain communication facilities as provided by SPACE.
Figure 2 presents the way interrupt handling is done in Adeos. Adeos uses an interrupt pipe 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. This, again, resembles SPACE's handling of interrupts as shown in figure 2 of [8], but behaves differently as to the way domains can control the interrupts they receive. That is, domains can control whether they accept, ignore, discard or terminate interrupts. Each of these has a different effect and is controlled differently.
Accepting interrupts is the normal state of a domain's interrupt mechanism. When Adeos encounters a domain who 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. As some OSes do not recognize Adeos, their idle task is modified to call on Adeos when it becomes scheduled. This is possible since the process tables of most operating systems are accessible from a device driver or module standpoint. Taking control of the idle task is done by way of loading a device driver or a module, finding the idle task's entry in the task table and replacing it with a function that issues a special trap that Adeos recognizes as a signal from the OS in the domain that it is done using the CPU. Of course, this special interrupt isn't propagated in the pipeline and is therefore invisible to all domains. If the OS recognizes Adeos, then he only needs to tell Adeos that he is now dormant. This informs Adeos that the interrupt can proceed onto the other stages of the pipeline. Of course from one pipeline stage to the next, Adeos needs to save the state of the domain that was running so as to restore it in the next pipeline traverse.
When an OS in a domain does not want to be interrupted, for any type of 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 unstall the pipeline and thereafter all the interrupts that were stalled at the corresponding stage follow their route to the other stages of the pipeline. Note that if new interrupts make their way through the pipeline while a stage is stalled they will remain at that stage and will be provided as new interrupts to the domain occupying that stage once the stage is unstalled. As some OSes do not recognize Adeos' presence, a way must be found to communicate the usual ``disable interrupt''/``enable interrupt'' or ``lower interrupt level''/''raise interrupt level'' instructions to calls of ``stall stage''/''unstall stage''.
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. The interrupt behavior for each domain and for individual interrupts may be changed dynamically.
Since some OSes do not recognize Adeos, it is possible to create a domain which only serves as a handler for that OS. Hence, during interrupt pipelining, 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 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 pertain to one of its particular implementations. The next section covers these details for the ix86 using Linux as the base OS.
