
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.

No hosted domain 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):
[1] D. Probert, J. Bruno, and M. Karzaorman. "Space: a new approach to
operating system abstraction." In: International Workshop on Object
Orientation in Operating Systems, pages 133-137, October 1991.
[2] D. Probert, J. Bruno. "Building fundamentally extensible application-
specific operating systems in Space", March 1995.
[3] D. Cheriton, K. Duda. "A caching model of operating system kernel
functionality". In: Proc. Symp. on Operating Systems Design and
Implementation, pages 179-194, Monterey CA (USA), 1994.
[4] D. Engler, M. Kaashoek, and J. O'Toole Jr. "Exokernel: an operating
system architecture for application-specific resource management",
December 1995.

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: http://www.opersys.com/adeos
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.

i386 and armnommu are currently supported. Most of the
architecture-dependent code is easily portable to other architectures.

Aside of adding the Adeos module (driver/adeos), we also modified some
files to tap into Linux interrupt and system event 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.

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.

Adeos' public API is fully documented here:
http://home.gna.org/adeos/doc/api/index.html.

In Linux's case, adeos_register_domain() is called very early during
system startup.

To add your domain to the ipipe, you need to:
1) Register your domain with Adeos using adeos_register_domain()
2) 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.

Over x86, Adeos supports SMP, and local/IO-APIC on UP.

Here are some of the possible uses for Adeos (this list is far
from complete):
1) 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.

2) 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.

3) 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.

4) 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.

5) 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.

Philippe Gerum <rpm@xenomai.org>
Karim Yaghmour <karim@opersys.com>

----------------------------------------------------------------------
Links to papers:
1-
http://citeseer.nj.nec.com/probert91space.html
ftp://ftp.cs.ucsb.edu/pub/papers/space/iwooos91.ps.gz (not working)
http://www4.informatik.uni-erlangen.de/~tsthiel/Papers/Space-iwooos91.ps.gz

2-
http://www.cs.ucsb.edu/research/trcs/abstracts/1995-06.shtml
http://www4.informatik.uni-erlangen.de/~tsthiel/Papers/Space-trcs95-06.ps.gz

3-
http://citeseer.nj.nec.com/kenneth94caching.html
http://guir.cs.berkeley.edu/projects/osprelims/papers/cachmodel-OSkernel.ps.gz

4-
http://citeseer.nj.nec.com/engler95exokernel.html
ftp://ftp.cag.lcs.mit.edu/multiscale/exokernel.ps.Z
----------------------------------------------------------------------
