L4 for asm-free OS'es?
William A. Gatliff
bgat at billgatliff.com
Mon Apr 8 18:16:11 CEST 2002
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.
--
Bill Gatliff
bgat at billgatliff.com
More information about the l4-hackers
mailing list