Re: For the AdaOS folks

["Marven Lee" <mehs60@dsl.pipex.com>]

Warren W. Gay VE3WWG wrote:
> Dmitry A. Kazakov wrote:
>> Warren W. Gay VE3WWG wrote:
>>> The problem then is that the drivers add to the code in "real-mode",
>>> which is one thing that the mk tries to avoid (for additional safety
>>> and modularity).
>>
>> I am still not sure what you mean here. If you mean modular kernel
>> design and more fine-grained system of modes than all-or-nothing,
>> then yes, sure. There is no reason, why a driver should not be
>> treated as an application.
>
> That's right. Just remember that the purpose of the mk is to keep the
> "priviledged-mode" code to a bare minimum (hence the "micro").

Some microkernels and single address space operating systems
implement cross-domain call mechanisms that enables a thread
to cross from one protection domain into another in a similar
way as a segmented system performs far calls or interrupts
and traps can transfer from user-mode to kernel-mode.

In Mach it's called "migrating threads".
The Spring Nucleus (and Solaris) has cross-domain calls through "Doors".
In the Pebble Operating System it's called "Portal Traversal"
Mungi has "Protection Domain eXtensions".
I think the Grasshopper kernel has something similar.
Maybe LPC in Windows is a form of cross-domain call, I'm not sure.

You can end up with a microkernel that only handles cross-domain
calls.  Everything else, including what you normally think
a microkernel should at least include, such as memory management,
scheduling and IPC can be implemented outside of the microkernel.



Marv