[Top][All Lists]

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

Re: The Hurd: what is it?

From: Marcus Brinkmann
Subject: Re: The Hurd: what is it?
Date: Wed, 09 Nov 2005 16:53:13 +0100
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i386-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 09 Nov 2005 14:15:30 +0100,
Sergio Lopez <koro@sinrega.org> wrote:
> I've searched many times through the mailing lists, and I didn't found
> a complete and rational discussion about the design issues of Mach/Hurd.
> Perhaps could be a good idea to start such discussion now, probably
> both l4-hurd and hurd will get benefit from this.
> If you feel like this is not the right time for that, could you please
> point me to that technical documentation? (That would be very helpful
> for me :-)

You want a _complete_ discussion?  Man, you are brave :)

For defects in Mach, try:


For hints on how a better kernel can look like:


For problems with multiple personalities on top of Mach:


Note that this work (IBM Workplace) already includes the work done by
Liedtke as far as it can be applied to Mach with only few
architectural changes.  This sheds some light on the prospect of
incremental improvements.

For problems with Mach's external pager interface, for example:


For problems with ACL-based authentication:


For problems with the Hurd passive translator design:


Active translators also must be considered harmful:


(There is not a complete explanation of all the possible problems, but
there are many examples, please use this as an opportunity for an
exercise---check out how Linux FUSE does it).

If you are looking at the actual Hurd implementation, you can find
plenty of denial of service attack possibilities, as well as denial of
resource attack possibilites.  No need to even try to enumerate them
all.  Note the absence of a quota system.  Note the absence of
feasibility to implement a quota system in such a multi-server system,
without some ground-breaking architectural changes.

Just as an illustration: The number of worker threads in the system
per server is unlimited.  It's not unusual for ext2fs to create 2000
threads on page pressure, because Mach swaps them out individually.
You can throttle, but not limit the number, because of the possibility
for deadlocks.  There are many things wrong with that, starting from
the simple fact that the number of threads in a server should be a
function of the server design, and not of the number of users or
system load.

And if you have digged through all this stuff, we have not even
_touched_ the subject of quality of service guarantees, resource
scheduling, and some other interesting things.

So, these are starting points.  Surely, you will be very interested in
reading all of these resources, and some more, if you want to
participate in the discussion.

There is no magic spoon that allows me to feed this material to a king ;)


reply via email to

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