[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Design goals
Jonathan S. Shapiro
Re: Design goals
Sat, 05 Nov 2005 13:26:15 -0500
Okay, here is a controversial one to consider:
The native Hurd OS should be a principle-based design
That is, the Hurd design should be constrained by a set of clearly
articulated design principles, and should reject, omit, or modify
features that do not satisfy these principles.
What is a design principle?
A design principle is a test that lets you *reject* things. Hopefully,
when combined with other design principles, it forms a basis for making
coherent and consistent decisions about design goals and system
"Hurd should be extensible" is not a principle. It is a design
goal. It is not a principle because it is not useful in rejecting
or filtering proposals.
"Hurd's extensibility should not increase the system's vulnerability"
is something very close to a principle. I do not consider it a good
a) it is expressed in terms of a feature, and
b) it feels to me, subjectively, like there must be some more
general principle that could be extracted from this one,
after which this would become a design constraint by consequence.
c) it is not quite capturing the right thing, because there are
certainly places in the system where extensibility might be
permitted in ways that would increase the vulnerability
of the system if done badly -- for example, we might want to
add a new network protocol.
"The system's software design should preclude an administrator being
able to examine a user's state without the user's consent" is a design
principle governing the role and powers of the system administrator.
I'm not sure that Hurd wants to adopt this principle; I am merely
saying that in my opinion it is an example of a design principle.
"The system should provide a uniform naming and protection mechanism
allowing new object types to be introduced by application-level code"
is a design principle governing the design of the naming and
protection mechanism. [It is imperfectly achievable, since we do not
currently know how to successfully extend the "read-only" property
to such objects in general, so user-implemented objects are not
really co-equal with kernel-implemented objects.]
"The set of things that must be implicitly trusted by an application
should be kept to a minimal and coherent set" is a design principle.
This would allow introducing new servers, but it means that a client
should not be deprived of the opportunity to reject those severs.
Under this principle, we would not extend the confinement contract to
consider a read-only file descriptor confined unless the client
application has agreed that the file server is trusted in the eyes of
the client application.
Enough examples. My proposal is that the Hurd native OS should be a
principle-based design. I am *intentionally* excluding hosted
personalities from this rule, because we want to include POSIX, and
POSIX will violate some of the principles that I think we will want in
the native OS.