L4 for asm-free OS'es?

William A. Gatliff bgat at billgatliff.com
Mon Apr 8 18:16:11 CEST 2002


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

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.  :^)

Bill Gatliff
bgat at billgatliff.com

More information about the l4-hackers mailing list