l4-hurd
[Top][All Lists]
Advanced

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

Re: design goals vs mechanisms


From: Jonathan S. Shapiro
Subject: Re: design goals vs mechanisms
Date: Thu, 27 Oct 2005 14:32:22 -0400

On Thu, 2005-10-27 at 20:18 +0200, ness wrote:
> You have pushed me into sth. I didn't expect. You say you have this huge 
> trea and there's no real list of goals?
> I can only quote the Hurd web page:
> 
>    it's free software
>    it's compatible
>    it's built to survive
>    it's scalable
>    it's extensible
>    it's stable

Free software is not a technical goal. It is a political goal. It may be
a good goal, but it does not help us reveal how Hurd should be built.

Compatibility also is not very helpful. There are many ways to be
compatible, so this doesn't really influence core decisions about the
design.

I think that "survivable" means some combination of "robust and
recoverable". This would strongly push us toward a system structured by
a larger number of smaller objects, each of which has a well-isolated
and testable function, and each of which lives inside an isolation
boundary and communicates only using specified and well-defined channels
of communication -- and this restriction is enforced!

Scalable is a nice goal, but it is rather vague. Scalable to very large
and very small systems, or scalable to large scale multiprocessors? You
probably cannot have both in a single system design, because the
architectural requirements are incompatible in some critical places.

Extensible? Linux is extensible. What is meant by extensible? What kinds
of extensions are permitted/encouraged? Under what conditions? By whom?
What guarantees are preserved about the system behavior when extensions
are introduced? Answers to these questions will be needed to drive
architecture.

Stable: this will also push us toward the general sort of design
philosophy that KeyKOS, EROS, and Coyotos adopted: smaller, well defined
objects that get securely composed. I do not claim that this philosophy
is any invention of ours -- it has existed in structural engineering and
aeronautics and electrical engineering for a long time. It just hasn't
been systematically applied in software before.

shap





reply via email to

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