Guys:
I'm an L4 newbie. I've booted it on my PC, I've read a lot of the online docs, and I've looked at some of the code. But I've been doing embedded systems for more than ten years now, so I know a thing or two about computers and operating systems.
I'm interested in using L4 as a foundation for a new, yet-to-be-written Linux replacement intended primarily for use in embedded systems. My main motivations are for an OS that is portable, is understandable, has low interrupt latency, and has a small memory footprint. I'm thinking along the same lines as L4-Linux, but my OS would probably be written in C++ and make more use of L4 servers for hardware i/o.
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?
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."
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. My customers think Linux is great because it's more portable than the alternatives, but I think it isn't nearly portable enough. And it scores low marks for understandability, interrupt latency and footprint. Oh, and debuggability---I love your "KD:" prompt! :^)
Thanks!
b.g.
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 ...
Cheers
Rob
---------------------------------------------------------------- Robert Kaiser email: rkaiser@sysgo.de SYSGO RTS GmbH Am Pfaffenstein 14 D-55270 Klein-Winternheim / Germany fax: (49) 6136 9948-10
Wow! Thanks for all the feedback, guys! :^)
I obviously need to tighten up my terminology a bit, and spend even more time in some L4 Kernel sources... (I have Hazelnut here now).
On Mon, Apr 08, 2002 at 05:41:50PM +0200, Robert Kaiser wrote:
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.
Yea, that's what I meant by "work the MMU". But you gave me the answer I was looking for--- that the Kernel owns the MMU, not user processes, *and* there's enough of a consistent API there that an OS running under an L4 Kernel need not concern itself with the MMU.
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.
Right. This is what I'm after.
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.
Sure. But it looks like the number of them gets smaller by going with L4. :^)
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
It's different when you make a living at it, of course, but not too different. I don't yet have the time, either! :^(
b.g.
Hi Bill,
I'm interested in using L4 as a foundation for a new, yet-to-be-written Linux replacement intended primarily for use in embedded systems. My main motivations are for an OS that is portable, is understandable, has low interrupt latency, and has a small memory footprint. I'm thinking along the same lines as L4-Linux, but my OS would probably be written in C++ and make more use of L4 servers for hardware i/o.
on the long run, I'm also trying to port NetBSD to L4; but I'm currently very far from this yet ;)
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?
If I understand the L4 X.2 spec of the upcoming Version 4 (Pistachio) right, the new API provides enough system independent hooks for accessing the MMU; which L4 would manage. Please look at the spec. Because the MMU is a central security sensitive area, it is very comprehensible to leave its management to the kernel. Most everything else can be factored out to userspace.
If you would like to implement some kind of VM system on top of that (this is seldom necessary for embedded systems, as you certainly know!), I'd recommend that you use NetBSD's UVM (or the older snapshot thereof in the latest OSKit release). Basically, the most work goes into writing a pmap.c for L4, which would use the L4 API to access the MMU; the rest of the working being to insulate UVM from the NetBSD parts like, say, VNODE pager stuff etc. Then again, who needs a swap file on embedded systems anyway? ;-)
BTW, pmap is the machine dependen physical layer to the various MMUs supported by BSD kernels, that UVM uses extensively.
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."
I'm rather sceptical if it would be possible to write an assembler-less OS on top of L4 V4, though I'm no expert here. After all, most interfacing to L4's C++ API would probably be done through header files that contain embedded/inline assembly or equivalent C constructs; just like in Hazelnut. But I'm no expert here!
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. My customers think Linux is great because it's more portable than the alternatives, but I think it isn't nearly portable enough.
For embedded systems, I really recommend NetBSD, which is architecturally and also practically the currently most portable OS in the world. This is not to speak against Linux, which is making progress in this area too, but NetBSD is IMHO lightyears ahead on portability and supports many more embedded systems at the moment; including the targets you're using.
Having a NetBSD/L4 port would be great; but the idea to write a whole new embedded OS from scratch is also intriguing.
And it scores low marks for understandability, interrupt latency and footprint. Oh, and debuggability---I love your "KD:" prompt! :^)
;-)
Bill Gatliff
-Farid.
Farid:
On Mon, Apr 08, 2002 at 05:45:08PM +0200, Farid Hajji wrote:
on the long run, I'm also trying to port NetBSD to L4; but I'm currently very far from this yet ;)
Great! The more the better.
I'm rather sceptical if it would be possible to write an assembler-less OS on top of L4 V4, though I'm no expert here. After all, most interfacing to L4's C++ API would probably be done through header files that contain embedded/inline assembly or equivalent C constructs; just like in Hazelnut. But I'm no expert here!
Right. I mean, that would be the goal, but I'll take "assembler-light" here as a good start. And no cheating with crafty and hard-to-debug inline asm macros!
For embedded systems, I really recommend NetBSD, which is architecturally and also practically the currently most portable OS in the world. This is not to speak against Linux, which is making progress in this area too, but NetBSD is IMHO lightyears ahead on portability and supports many more embedded systems at the moment; including the targets you're using.
Yea, it's on my list. Honest.
Maybe that makes sense, to start with an l4 port of NetBSD instead of Linux... Hmmm...
Having a NetBSD/L4 port would be great; but the idea to write a whole new embedded OS from scratch is also intriguing.
A clean slate is what I'm after in the long run, but I'm not in any rush.
A lot of what I see happening in the C parts of Linux could be done *so* much better with C++. I'm thinking of an OO-oriented driver model as an example, rather than just a soup of C functions that you have to invoke in the proper order for things to work right. "Want to right a USB driver? Well then just inherit from USBDriver and fill in these functions for the bulk transfers." You know, like that. :^)
I also *hate* how dynamic memory management is so in-your-face in the kernel. It doesn't need to be so manual, and making it more automagic would reduce lines of code *and* the potential for errors. C++ is great for that kind of stuff.
And it scores low marks for understandability, interrupt latency and footprint. Oh, and debuggability---I love your "KD:" prompt! :^)
;-)
... I'd like it even better if it could talk to gdb. :^)
b.g.
William A. Gatliff wrote:
A lot of what I see happening in the C parts of Linux could be done *so* much better with C++. I'm thinking of an OO-oriented driver model as an example, rather than just a soup of C functions that you have to invoke in the proper order for things to work right. "Want to right a USB driver? Well then just inherit from USBDriver and fill in these functions for the bulk transfers." You know, like that. :^)
You probaly want to have a look at MacOS X / Darwin and its IOKit. Thats exactly what they do.
Patrick
[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
l4-hackers@os.inf.tu-dresden.de
-
Espen Skoglund -
Farid Hajji -
Patrick Strasser -
Robert Kaiser -
William A. Gatliff