The following reply initially went only to Ness because he had forgotten to CC the list. At his request, I am now sending it to the list.
shap -------- Forwarded Message -------- From: Jonathan S. Shapiro <[EMAIL PROTECTED]> To: ness <[EMAIL PROTECTED]> Subject: Re: On hierarchy Date: Fri, 21 Oct 2005 16:36:32 -0400 Ness: Your reply did not go to the list, so I am replying privately. If you intended your note to go to the list, please send this out too? Thanks shap On Fri, 2005-10-21 at 22:19 +0200, ness wrote: > > What *I* am saying is: the kernel must not include *any* operation that > > would *ever*, under *any* circumstances, exceed log(n) time (n = number > > of in-memory objects). > > > OK, this is your opinion. But you say this is only necessary for > real-time capabilities. In my eyes, the system should decide whether it > wants those rt-caps or not. Yes. If you are willing to give up resource-constrained audio and video, and the "general purpose" claim, you can certainly decide to give this up. Also you must give up any hope at high-assurance certification, which requires that covert channels be characterizable. These are not necessarily bad decisions. But it has been my observation that processors are much more reliable than most OS kernels. One reason for this is that they are designed to run in fixed resource and bounded time. I am not (yet) able to articulate what it is about these constraints that makes high-robustness software easier, but there is an overwhelming body of empirical evidence that a massive difference in robustness really does exist. If you are satisfied with a system that stays up for a week or a month at a time, then you may not need to go as far as this. Eventually, I want to see the Coyotos kernel used in life-critical applications. The personal metric I use for "good enough" is: would I run it on my own pacemaker? shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
