[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: L4Hurd at Sourceforge

From: Farid Hajji
Subject: Re: L4Hurd at Sourceforge
Date: Tue, 23 Oct 2001 02:25:25 +0200 (CEST)

> > > I really dislike fiaco because it is written in C++, IMHO C is better f=
> or
> > Fiasko is not that bad. It's not as fast as the L4Ka, but fast enough
> > and compatible to the other X86-L4 kernels. Thus you don't need to worry
> > about which L4 microkernel you are using. The V-Fiasko also looks quiete
> > promissing.
> > But if you want the L4Ka, then look at the CVS repository at
> > sourceforge.
> > Some C-Bindings are also available there.
> As most of them are compatible it doesn't matter much, however I prefer
> hazelnut. I already have run it and looked at the code. Fiasco however
> didn't compile for me. I don't know the opinion of ther people. :)
Fiasco did compile on my BSD system as well, but I had to struggle with
the oskit/oskit10 stuff before being able to compile fiasco there. L4Ka/
Hazelnut compiled without any problems both on Linux and BSD.

> > I think at this stage it is much more critical to get a good system
> > structure and start codeing some prelimary server to test this
Yes, please see my previous mail outlining a possible organization
for the CVS repository.

> > > a microkernel and the GNU Coding Standards also recommends using C. Haz=
> elnut
> > > uses a few bytes of C++ which are easy to remove AFAICS, so it's a
> > These few lines of C++ are only for convenience. There shouldn't be a
> > difference in performance to a pure C kernel at all. What's the problem
> > with these few lines at all?
> If we are going to use a L4 variant we probably need to change code, to
> fix bugs or for other reasons. As my C++ knowledge isn't that great and
> that of other people maybe worse, it's easier to have a C
> implementation.
Please submit L4 changes/fixes to the appropriate teams.

I doubt that it is even a good idea to meddle around with L4 itself.
L4 developers go to great lenghts to keep the kernels minimal and try
to move as much as possible _outside_ of the kernel. IIRC, someone
is even doing research on a user-mode scheduler!! Considering this,
and using Michael's user-level driver framework, I'm pretty sure that
_we_ (l4-hurd developers) won't need to touch the L4 internals at all.


Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555
Broicherdorfstr. 83, D-41564 Kaarst, Germany  | address@hidden
- - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - -
One OS To Rule Them All And In The Darkness Bind Them... --Bill Gates.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]