L4 for asm-free OS'es?

Robert Kaiser rob at sysgo.de
Mon Apr 8 17:41:50 CEST 2002

On Mon, 8 Apr 2002, William A. Gatliff wrote:

> Here are my questions:
> One of the L4 manuals I've read says that when an OS running under L4
> starts, it should take all free memory from sigma0 and then manage the
> pages itself.  To me, this means that the OS has to know how to
> interact with the host CPU's MMU hardware, which is obviously
> hardware-dependent and therefore undesirable in a portable OS.  It
> also appears to be redundant--- sigma0 already knows how to work the
> MMU.

If by "work the MMU" you mean to setup/manipulate page tables etc.,
then no, neither sigma0 nor any other entity outside the µkernel
knows how to work the MMU. The Kernel provides a platform independent
mechanism (IPC) for pages to migrate between different processes. So, if a
process owns a set of pages, it can map or grant (some of) these pages to
another process. The reciever of the pages can map (some of) these pages
on to another process, and so on.

In this way it is possible to build address spaces in a recursive
manner. Sigma0 is the first process (well, actually it is better to say it
is the "first address space") and it owns all pages at the start.

>  Performance issues aside, would letting sigma0 do page mapping
> and unmapping eliminate the need for an OS running under it to know
> how the MMU interface works, and thereby make the OS a little more
> portable?  Is this a reasonable approach?

After what's been said above I think it is probably clear now that
this is already how things work with L4. However it is not sigma0
that does the mapping, but the kernel. Note that L4 strictly seperates
between policy and mechanism: the kernel provides only the mechanism
(i.e. how to "work the MMU"), while all the policy (e.g. page replacment
algorithms, etc.) is to be implemented in user space.

> What is the likelihood that an L4-based OS would need no assembly
> language at all, other than the syscall interface?  I'm thinking along
> the lines of "to port this OS to your CPU, just port L4 and then
> recompile the OS sources."

There are e few things besides the syscall interface that are (and will
always remain) platform dependent, though they need not necessarily
be implemented in assembly language. The original x86 L4 for example
uses an emulation of the x86 LIDT instruction to set up exception
handlers, which is obviously totally non-portable. This has apparently
been abandoned in the new Version 4 API definition, where exceptions
are transformed into IPC messages by the kernel. However, an exception
handler usually needs to be able to access individual CPU registers of
the faulting process. This can be done in C, but the Code is inherently
platform dependent to some extent.
Nevertheless, if you look at something the size of the Linux kernel, I
believe it would be possible to implement such a thing with a _very_ low
percentage of platform dependent code.

> I'm eyeing ARM, MIPS, SH and x86 targets--- all of which I work with
> every day.  I have single-board computers representing all four
> architectures in my lab here right now, and I'm doing something with
> all of them almost all the time.  That's why portability is important
> to me. 

It all sounds so familiar ... Apparently I have interestst very similar to
yours :-). My main problem is time to actually _do_ all these nice things



Robert Kaiser                          email: rkaiser at sysgo.de
Am Pfaffenstein 14
D-55270 Klein-Winternheim / Germany    fax:   (49) 6136 9948-10

More information about the l4-hackers mailing list