| 词条 | Adaptive Domain Environment for Operating Systems |
| 释义 |
| name = Adeos | title = | logo = | logo caption = | logo_size = | logo_alt = | screenshot = | caption = | screenshot_size = | screenshot_alt = | collapsible = | author = | developer = | released = | discontinued = | latest release version = | latest release date = | latest preview version = | latest preview date = | status = | programming language = | operating system = | platform = | size = | language = | language count = | language footnote = | genre = | license = | website = {{URL|http://www.opersys.com/adeos}} }} Adeos (Adaptive Domain Environment for Operating Systems) is a nanokernel hardware abstraction layer (HAL) or a hypervisor that operates between computer hardware and the operating system that runs on it.[1] It is distinct from other nanokernels, in that it is not just a low level layer for an outer kernel. Instead it is intended to run several kernels together, which makes it similar to virtualization technologies. Adeos provides a flexible environment for sharing hardware resources among multiple operating systems, or among multiple instances of a single 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 SMP clustering, more efficient virtualization, patchless kernel debugging and real-time 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. In fact Adeos was developed in the context of RTAI (Real-Time Application Interface) to modularize it and to separate the HAL from the real-time kernel. Previous WorkThere are two categories of existing solutions that 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 usage of a nanokernel layer to enable hardware sharing.[1] In the simulation category there are tools such as VMware, Plex86, VirtualPC and SimOS. There is also KVM which is more similar to Adeos but is not RT and requires specific virtualization hardware support. These solutions are used for users who desire to run applications foreign to their base OS, they provide no control whatsoever 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. The problem of this approach is that it does not address the issue of currently existing 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 usage, by the different OSes, more than is necessary for Adeos’ own operation. Instead, that actual 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] ArchitectureAdeos 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 usage of the hardware except as needed for its own survival. The task of determining policy is left to the system architect.[1] Adeos Interrupt PipeAdeos 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. 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] ApplicabilityGeneral-purpose operating system resource sharingGeneral-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 DevelopmentDeveloping OSes is usually a complicated process which sometimes requires extra hardware such as In-Circuit Emulators to probe the hardware on which the 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] Patch-less Kernel Debuggers and ProbersAdeos 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] See also{{Portal|Free and open-source software}}
External links
References1. ^1 2 3 4 5 6 7 8 9 10 11 12 Adaptive Domain Environment for Operating Systems. www.opersys.com/ftp/pub/Adeos/adeos.pdf. Retrieved 2012-04-27 {{Virtualization products}}{{MicroKernel}} 2 : Nanokernels|Virtualization software |
| 随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。