L4 for asm-free OS'es?

[Espen Skoglund]

[William A Gatliff]
> 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.  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?

User-level servers (including sigma0) need not know anything about the
host machines MMU.  Memory management is done by mapping/granting
fpages to other servers and possilby later on revoking the mappings
using the unmap syscall.

Of course, a memory management server (e.g., L4Linux) must know which
page sizes are supported by the architecture.  It can not map,
e.g., a 4KB fpage if the architecture supports a minimum page size of
8KB.  In the Version 4 API specification this issue is solved by
having the a field in the Kernel Interface Page specifying which page
sizes are supported.

> 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."

This really depends on the your system.  Writing drivers will for
instance require some interaction with the underlying hardware.  This
can often only be achieved using architecture specific instructions
(e.g., inb/outb).  One might also want to perform certain semaphore
operations like compare-and-exchange, and these operations can not
readily be mapped to their hardware instruction counterparts using
portable C.  Then there is problem of handling exceptions (i.e.,
understanding what can cause, e.g., a floating point or misaligned
access exception, and knowing how to handle it properly).  There's
also the deal of how to go about locating, managing and using hardware
devices in the system.  The kernel does not try to interfere in this
process.

	eSk