Fare's kernel definition

Mike Prince mprince@crl.com
Fri, 23 Dec 1994 20:08:30 -0800 (PST)


I'm kind of getting tired of this kernel argument.  It has gone on too 
long already.  We are here to build something better.  It is useless to 
say something is bad without suggesting a better alternative.

It is also a waste of time to define something as bad, and then use your 
definition as the 

On Fri, 23 Dec 1994, Francois-Rene Rideau wrote:
> ### What I call a kernel ###

> a kernel is some piece of code that *must* be called whenever different
> system objects want to communicate (i.e. a syscall manager).

This is your definition of what most kernels do.  The kernel I am 
proposing does not do this, so your definition does not apply.  All this 
statement accomplishes is confusing the issue by 

> It introduces
> some useless and harmful overhead

Care to explain?  Some kernels have wasted code, but just because some 
have done it poorly, does that mean we can't do it right?

> and prevents fine-grained system objects
> from being efficiently implemented,

Again, implementation specific.  Does not apply to all kernels.

> while not being able to bring any
> useful functionality.

Purely subjective.

> It can also implement only stubborn or completely
> inefficient security mechanisms (see Unices, or VSTa)

Case dependent and subjective.

> when a no-kernel
> scheme can cope with any kind of security complexity.

See my prior post about how saying nothing is better than something means 
nothing.

Your argument seems to rest on finding faults in some kernel designs, and 
then saying that no kernel can be built without those flaws.  This is not 
sound logic.  Please show me a proof that I _cannot_ build a kernel without 
having these flaws.

Mike