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