a no-kernel system

[Mike Prince]

On Fri, 23 Dec 1994, Francois-Rene Rideau wrote:
> ### What I call a kernel ###
> 
>   Firstly, let me say again what a kernel is:
> a kernel is some piece of code that *must* be called whenever different
> system objects want to communicate (i.e. a syscall manager). It introduces
> some useless and harmful overhead, and prevents fine-grained system objects
> from being efficiently implemented, while not being able to bring any
> useful functionality. It can also implement only stubborn or completely
> inefficient security mechanisms (see Unices, or VSTa), when a no-kernel
> scheme can cope with any kind of security complexity.
>   Re-read my previous message. The mailing-list archive is on
> frmap711.mathp7.jussieu.fr:pub/scratch/rideau/moose/TUNES/mailing-list-archive,
> if you've lost it.
> 
> [As for Mike,
> 
> 2) yes, we'll provide standard objects to solve as much problems as we can,
> but no, they won't constitute a kernel. They will be replaceable, and third
> parties will be able and encouraged to provide compatible, incompatible, or
> completely new objects to replace them. Any object provider including us

In order for my object to replace anothers (upgrading);
	1.  I must know what services the old object provides.  How does my
		new object find that out?
	2.  In a persistent system, you don't restart the computer when you
		upgrade, you must inherit the state of the prior object.  How
		does this happen?  Does the old object provide the info?  Or
		does the OS have some way of capturing it?  How do you
		identify and use the old objects data structures?

>    Because there will be a world-wide net, new modules will spread quickly,
> and selection of the fittest will be fast, so that there will be no problem
> of "I don't have this module" or "I need tons of different but equivalent
> modules".

We might be viewing computers differently.  I have the impression Fare is 
focused on the standard processor box (1..n processors on one users desk, 
with some disks).  Your box, under your scheme, would collect a working 
set of modules.

But what if the rules changed.

Objects frequently migrate.  Now it's much tougher to maintain a working 
set.

Links aren't stable or fast.  You don't have that required module, and 
you have no way of getting it (or getting it fast).

Modules characteristics change over space/time (scoping causes different 
modules under same name at different times to be acessable).

You can only afford very small computers (embedded).  When you're fighting
over a wasted byte, who can afford to support multiple standards?

One thing you forget is the nature of businesses to support everything so 
their users don't get pissed about a particular format not being 
accessable.  If you foster the creation of multi-standards, then our beast 
will grow large.

> translation to adapt programs from one interface to the other will also
> be common and help remove obsolete modules from the surface of earth.

See my previous questions.

> ### Security ###
> 
>    Raul raised the security problem. I say that the no-kernel concept allows
> far more security than any kernel.

It doesn't make sense to say that nothing allows more security than 
something.

>    Raul seems to believe that code should always be allowed to crash, and
> thus a virtual-machine kernel would be needed for security. But why
> should code always be allowed to crash ? For "performance" ? How performant
> is a program that may crash ? Not at all, everyone will tell you (especially
> in the industry). Are you happy with programs that crash ? No I'm sure.
> So let's just not admit crashable programs.

There is no way you can weed out all the crashable programs.  A simple 
example is a program waiting for an event that will never happen.  
Another example is faulty hardware, when a bit in a "safe" program 
becomes corrupt (or you use FDIV to lookup pointer values).  The ONLY way 
around this is hardware isolation of programs and recovery mechanisms.
This is a necessity if we want persistent systems. 

> There exist well-known
> techniques (type/bound/assertion checking, either static or dynamic) to
> prevent any crash.

These won't fix the prior problems at all.

>   As for programming bugs that may appear despise any decidable
> crash-proofing mechanisms (see Turing's fundamental theorems), there are
> also well-known techniques for proving program correctness, so why not use
> them, and refuse any unproven program ? Of course, a "root" user could say
> "admit it" as a program proof, and that's what we'd use in the meantime.

See prior.

>   As for Mike, no, I'm not too harsh with microkernels. Get subscribed to
> the VSTa mailing-list if you don't believe me.
[snip]
> Yes, I mean it. Please tell why my arguments don't stand, and
> argue otherwise before you can say I'm too harsh.

See my next post about kernels.

Mike