[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