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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
