[Top][All Lists]

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

Re: Hurd questions

From: Farid Hajji
Subject: Re: Hurd questions
Date: Sun, 9 May 2004 14:27:19 +0200

> I saw a manual, but was for the old API, that's not good.

Visit http://l4ka.org/ and pick up the newest X.2 R5 API reference manual.

> Why gnumach was considered deprecated?

Mach is no longer considered state-of-the-art in the OS research area.
IPC high latency is one, but not the only reason for this. There is a
lot of literature/papers about this on the Net. Feel free to browse.
L4 is under active development, currently at least at three Universities
(perhaps more). L4 is also used in embedded systems in misc. electronics
labs, though they don't go public about it.

> Has Hurd different levels?
>         1- A generic part which doesn't change.
>         2- A different part that changes to interact with different 
> microkernels.

If it had, we would already have a working Hurd/L4 implementation.
Hurd was intimately tied to the Mach API when it was first conceived,
perhaps because Mach was the only microkernel back then. The goal of
the Hurd/L4 project is exactly that: trying to build layers in the
Hurd. An upper layer would be uKernel agnostic, and the other would
interact with the microkernel (be it Mach, L4 or some kind of virtual
machine). Doing this is difficult and requires a lot of thought, because
we've got to use different paradigms in the IPC model.

> If source code it's so difficult to understand but we have the
> references, is it possible to make our own L4 implementation of the
> L4?, with everithing documented? Something like GNU L4.

See my previous post. L4::Pistachio being under a 2 clause BSD
license is not considered a problem in the Hurd/L4 project.
It is a non-issue, because the BSD license is GPL compatible.
We also don't need a (most likely) suboptimal re-write of L4,
  a. we don't have the personal capacity in our small group to do it,
  b. L4 is still evolving and we would always lag behind with our
     own hypothetical implementation
  c. we simply don't need to duplicate efforts from fellow groups
     that are doing a terrific job.

Having said this, we need special glue code in Hurd/L4, like
a C++ -> C mapping library etc. Marcus already wrote code for
this that you can find in the hurd-l4 CVS repository. Feel free
to extend this if you understand the issues at hand. Another
big aspect is the device driver framework, which would enable
us to attach existing (Linux, BSD, ...) device drivers to L4
(e.g. as userland tasks). There is work-in-progress in this ara
too, and you're more than welcome to help out.

> If they don't want to cooperate, then we should make our own work.

The group at Karlsruhe (the L4::Pistachio creators) and the rest
of the L4 community is not only cooperating with us, they are
extremely helpful. I'm pretty sure that they would be more than
happy to see a Hurd/L4 version spring into existence, if only
to make measurements and publish papers about it ;-). What we
can't expect from them though, is that they provide people to
do our own job. They provide an excellent kernel and tools like
an IDL compiler (and docs). It's our job to code against this
layer and to connect the dots (so to speak) between the current
Hurd codebase and the L4 API.

> I think documentation is the most important for GNU sotware.
> Hurd page isn't actualized.  Why?
> No links to diagrams there, no project goals, no functionalities, no "to do" 
> list.
> No explanation about how to start.

There are some pages, but you're right. We simply don't have enough
(knowledgeable) people to sit down and write a decent architectural
overview of the Hurd. Currently, the only way to learn about the
internals is to grab the latest CVS sources, and to lock yourself
in your room for a couple of weeks while diving in. This is obviously
not the best way to recruit new developers. Then again, a beginner's
task could be to learn by reading the source, and write a tutorial
or manual or diary _while_ learning. Dare to try? It would be a great

> Should we make the hurd run on different microkernels or make especific 
> microkernels for the hurd? What is better?

Hmmm, that's an interesting question.

> José Salavert Torres
> E-mail: address@hidden, address@hidden
> Web: http://www.telefonica.net/web/josator


Farid Hajji. http://www.farid-hajji.net/address.html

reply via email to

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