Adeos nanokernel for Linux kernel

By Linux Devices
2002-06-03

Article Rating:

/ 0

Rate This Article:

Add This Article To:

[Note: This article appeared initially on the linux-kernel mailing list (LKML)] We have released the initial implementation of the Adeos nanokernel. The following is a complete description of its background, its implementation, its API, and its potential uses.

Please also see the press release and the project's workspace. The Adeos code is distributed under the GNU GPL.

The Adeos nanokernel is based on research and publications made in the early '90s on the subject of nanokernels. Our basic method was to reverse the approach described in most of the papers on the subject. Instead of first building the nanokernel and then building the client OSes, we started from a live and known-to-be-functional OS, Linux, and inserted a nanokernel beneath it. Starting from Adeos, other client OSes can now be put side-by-side with the Linux kernel.

To this end, Adeos enables multiple domains to exist simultaneously on the same hardware. None of these domains see each other, but all of them see Adeos. A domain is most probably a complete OS, but there is no assumption being made regarding the sophistication of what's in a domain.

To share the hardware among the different OSes, Adeos implements an interrupt pipeline (ipipe). Every OS domain has an entry in the ipipe. Each interrupt that comes in the ipipe is passed on to every domain in the ipipe. Instead of disabling/enabling interrupts, each domain in the pipeline only needs to stall/unstall his pipeline stage. If an ipipe stage is stalled, then the interrupts do not progress in the ipipe until that stage has been unstalled. Each stage of the ipipe can, of course, decide to do a number of things with an interrupt. Among other things, it can decide that it's the last recipient of the interrupt. In that case, the ipipe does not propagate the interrupt to the rest of the domains in the ipipe.

Regardless of the operations being done in the ipipe, the Adeos code does __not__ play with the interrupt masks. The only case where the hardware masks are altered is during the addition/removal of a domain from the ipipe. This also means that no OS is allowed to use the real hardware cli/sti. But this is OK, since the stall/unstall calls achieve the same functionality.

Our approach is based on the following papers (links to these papers are provided at the bottom of this message):

If you don't want to go fetch the complete papers, here's a summary. The first 2 discuss the Space nanokernel, the 3rd discussed the cache nanokernel, and the last discusses exokernel.

The complete Adeos approach has been thoroughly documented in a whitepaper published more than a year ago entitled "Adaptive Domain Environment for Operating Systems" and available here. The current implementation is slightly different. Mainly, we do not implement the functionality to move Linux out of ring 0. Although of interest, this approach is not very portable.

Instead, our patch taps right into Linux's main source of control over the hardware, the interrupt dispatching code, and inserts an interrupt pipeline which can then serve all the nanokernel's clients, including Linux.

This is not a novelty in itself. Other OSes have been modified in such a way for a wide range of purposes. One of the most interesting examples is described by Stodolsky, Chen, and Bershad in a paper entitled "Fast Interrupt Priority Management in Operating System Kernels" published in 1993 as part of the Usenix Microkernels and Other Kernel Architectures Symposium. In that case, cli/sti were replaced by virtual cli/sti which did not modify the real interrupt mask in any way. Instead, interrupts were defered and delivered to the OS upon a call to the virtualized sti.

Mainly, this resulted in increased performance for the OS. Although we haven't done any measurements on Linux's interrupt handling performance with Adeos, our nanokernel includes by definition the code implementing the technique described in the abovementioned Stodolsky paper, which we use to redirect the hardware interrupt flow to the pipeline.

In terms of implementation, the Adeos' code is rather short since we focused on setting the foundations for sharing interrupts between domains. Here are the files we added:

As you can see, only the i386 is currently supported. Nonetheless, most of the architecture-dependent code is easily portable to other architectures.

We also modified some files to tap into Linux interrupt dispatching (all the modifications are encapsulated in #ifdef CONFIG_ADEOS/#endif):

We modified the idle task so it gives control back to Adeos in order for the ipipe to continue propagation:

arch/i386/kernel/process.c We modified init/main.c to initialize Adeos very early in the startup.

Of course, we also added the appropriate makefile modifications and config options so that you can choose to enable/disable Adeos as part of the kernel build configuration.

Here is Adeos' public API:

In Linux's case, adeos_register_domain() is called very early during system startup. set_intr_gate() in arch/i386/kernel/traps.c is then modified to call on adeos_virtualize_irq() so that Linux would tell the ipipe that it needs the irq passed to set_intr_gate().

To add your domain to the ipipe, you need to:

Register your domain with Adeos using adeos_register_domain()
Call adeos_virtualize_irq() for all the IRQs you wish to be notified about in the ipipe

That's it. Provided you gave Adeos appropriate handlers in step #2, your interrupts will be delivered via the ipipe.

During runtime, you may change your position in the ipipe using adeos_renice_domain(). You may also stall/unstall the pipeline and change the ipipe's handling of the interrupts according to your needs.

We currently don't support SMP, but we do have APIC support on UP.

Here are some of the possible uses for Adeos (this list is far from complete):

Much like User-Mode Linux, it should now be possible to have 2 Linux kernels living side-by-side on the same hardware. In contrast to UML, this would not be 2 kernels one ontop of the other, but really side-by-side. Since Linux can be told at boot time to use only one portion of the available RAM, on a 128MB machine this would mean that the first could be made to use the 0-64MB space and the second would use the 64-128MB space. We realize that many modifications are required. Among other things, one of the 2 kernels will not need to conduct hardware initialization. Nevertheless, this possibility should be studied closer.
It follows from #1 that adding other kernels beside Linux should be feasible. BSD is a prime candidate, but it would also be nice to see what virtualizers such as VMWare and Plex86 could do with Adeos. Proprietary operating systems could potentially also be accomodated.
All the previous work that has been done on nanokernels should now be easily ported to Linux. Mainly, we would be very interested to hear about extensions to Adeos. Primarily, we have no mechanisms currently enabling multiple domains to share information. The papers mentioned earlier provide such mechanisms, but we'd like to see actual practical examples.
By incorporating Adeos into the main kernel tree (I know my inbox is probably going to fill up because of this one), kernel debuggers' main problem (tapping into the kernel's interrupts) is solved and it should then be possible to provide patchless kernel debuggers. They would then become loadable kernel modules.
Drivers who require absolute priority and dislike other kernel portions who use cli/sti can now create a domain of their own and place themselves before Linux in the ipipe. This provides a mechanism for the implementation of systems that can provide guaranteed realtime response. Of course, we are interested in hearing about comments and suggestions you have about Adeos.

Links to papers:
Related stories:
Discuss Adeos nanokernel for Linux kernel

>>> Be the FIRST to comment on this article!

>>> More Linux For Devices Articles Articles >>> More By Linux Devices

Email Article To Friend ♦ Print Version Of Article ♦ PDF Version Of Article

FUEL Database on MontaVista Linux
Whether building a mobile handset, a car navigation system, a package tracking device, or a home entertainment console, developers need capable software systems, including an operating system, development tools, and supporting libraries, to gain maximum benefit from their hardware platform and to meet aggressive time-to-market goals.

Breaking New Ground: The Evolution of Linux Clustering
With a platform comprising a complete Linux distribution, enhanced for clustering, and tailored for HPC, Penguin Computing¿s Scyld Software provides the building blocks for organizations from enterprises to workgroups to deploy, manage, and maintain Linux clusters, regardless of their size.

Data Monitoring with NightStar LX
Unlike ordinary debuggers, NightStar LX doesn¿t leave you stranded in the dark. It¿s more than just a debugger, it¿s a whole suite of integrated diagnostic tools designed for time-critical Linux applications to reduce test time, increase productivity and lower costs. You can debug, monitor, analyze and tune with minimal intrusion, so you see real execution behavior. And that¿s positively illuminating.

Virtualizing Service Provider Networks with Vyatta
This paper highlights Vyatta's unique ability to virtualize networking functions using Vyatta's secure routing software in service provider environments.

High Availability Messaging Solution Using AXIGEN, Heartbeat and DRBD
This white paper discusses a high-availability messaging solution relying on the AXIGEN Mail Server, Heartbeat and DRBD. Solution architecture and implementation, as well as benefits of using AXIGEN for this setup are all presented in detail.

Understanding the Financial Benefits of Open Source
Will open source pay off? Open source is becoming standard within enterprises, often because of cost savings. Find out how much of a financial impact it can have on your organization. Get this methodology and calculator now, compliments of JBoss.

Embedded Hardware and OS Technology Empower PC-Based Platforms
The modern embedded computer is the jack of all trades appearing in many forms.

Data Management for Real-Time Distributed Systems
This paper provides an overview of the network-centric computing model, data distribution services, and distributed data management. It then describes how the SkyBoard integration and synchronization service, coupled with an implementation of the OMG¿s Data Distribution Service (DDS) standard, can be used to create an efficient data distribution, storage, and retrieval system.

7 Advantages of D2D Backup
For decades, tape has been the backup medium of choice. But, now, disk-to-disk (D2D) backup is gaining in favor. Learn why you should make the move in this whitepaper.