Re: design goals vs mechanisms (was: Re: Let's do some coding :-)

[Jonathan S. Shapiro]

On Wed, 2005-10-26 at 22:43 +0200, Bas Wijnen wrote:
> On Wed, Oct 26, 2005 at 10:16:47PM +0200, Marcus Brinkmann wrote:

> Ok, so the current list of goals is:
> - security (needs to be more specific)
> - confinement
> - confinement with endogenous verification
> - persistance
> - no ACLs
> - persistent sessions for users
> - hard real time
> - soft real time
> - stability
> - robustness (what's the difference with stability?)
> - small memory footprint
> - support for legacy applications
> 
> I'd say all of them are nice. :-)  But it may be possible that we need to
> choose some and drop others.

I do not currently know how to achieve hard real time and transparent
persistence at the same time.  Soft real time does not appear to be a
problem.

The difficulty with hard real time is that the amount of work required
for persistence is proportional to the amount of dirty memory. This can
be scheduled, but only if we set bounds on the number of pages that can
be dirtied. Usually we do not do this.

However, I do not think that this is a big issue. In practice, hard
real-time systems are only possible when resource requirements can be
statically stated anyway. Most of these systems are not persistent, or
require only very specialized persistence.

Therefore, I would recommend dropping "hard real time" from the list of
goals, but I would also recommend that we should try to maximize the
flexibility of the soft real time elements of the design.

> > I think in the end we will be faced with a dilemma: Either we have to accept
> > the logical consequences of our stated design goals, which may be deep.
> > This includes removing any paradoxes by dropping some in a set of
> > conflicting design goals.  Or we drop some of our design goals to open up
> > space for other engineering mechanisms.
> > 
> > What's it gonna be?
> 
> Eh...  What did you just say?  Either we drop some goals so the rest is
> possible, or we make the rest possible by dropping some goals?  I don't think
> I understand the dilemma...

The dilemma is that you can't get all of what you want all of the time,
and sooner or later you are going to run into a place where something
has to give. When that time comes, it is going to be very tempting to
give up a design principle.

One of the reasons that UNIX succeeded so well for so long is that it
mostly resisted this temptation. There was a small list of design
principles, closely followed with very very rare exceptions. Whatever
principles you choose for the design, I would say: stick to them firmly.

shap