l4-hurd
[Top][All Lists]
Advanced

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

Re: Would Hurd be able to become a distributed OS?


From: Patrick Strasser
Subject: Re: Would Hurd be able to become a distributed OS?
Date: Fri, 10 Nov 2000 20:29:12 +0100

Farid Hajji wrote:
> 
> Jean-Philippe BOISSEAU wrote Fri, 10 Nov 2000 14:00:41 +0100):
> > A friend and I were wondering about relevancy of a distributed os.
> > When we discovered Mach concept, as implemented in Hurd, whe thought
> > about an os that would run on several machines, as current OSes run
> > on several cpus of the same machine.
> > Of course, there are latency problems, because of network speed and
> > determinism.
> Distributing the Hurd over several machines, each of one running Mach
> is possible, if some assumptions are met. However, you won't be happy
> with the resulting efficiency penalty at all.

> 
> A very interesting paper about distributed systems is:
> 
>   Load Distribution: Implementation for the Mach Microkernel
>   Dejan S. Milojicic
>   Vieweg Advanced Studies in Computer Science
>   ISBN 3-528-05424-7

I read  Distributed operating systems
        Andrew S. Tanenbaum
        Prentice-Hall Internat. 1995
        ISBN 0-13-219908-4

It has some chapters about Mach, comparing to Amoeba as Microkernel and
and Chorus.

> 
> I did some distribution experiments with CMU-Mach, osfmach (from the
> mklinux project) and rtmach (from keio/ntt) together with the Lites
> single server BSD OS personality. The results seem to confirm Dejan's
> impression, though I didn't test that much. I finally came to the
> conclusion, that Mach was the real problem right now. That's why

Mach is a big problem. Wouldn't be a way to slim Mach and move all the
drivers to userland? Mach is naturally a big big microkernel due to its
rich interface. Then integrating NORMA an alike could be easier as
general maintenance and improvement would.
 
> I didn't resume the tests on the Hurd.
> 

>   5. Being able to freeze a task and resume it on another node
>      has the nice side-effect of being able to save it to disk
>      and load it some time in the future (modulo broken connections).
>      (This is useful for laptops that could be turned off without
>       loosing their state)

Nice idea, some kind of didtributetd/multiserver/asynchronous Power
Management?

Patrick



reply via email to

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