Fare's kernel definition

[Mike Prince]

On Wed, 28 Dec 1994, Francois-Rene Rideau wrote:
>    Now, either you agree with this definition or you don't. If you
> don't, then let's say your definition. But do not say you disagree
> because you read my messages with your definition

All I'm saying is your kernel definition is too restrictive.

>    Now, with this definition of a kernel, the problem with kernels is
> that a kernel is some compulsory interface between objects

Now I'll agree that you're reading me correctly!  I'm absolutely for a 
compulsory interface between objects.  

>    Directly linked objects are *always* faster than objects that communicate
> through a kernel.

I'll agree again.  You've been assuming calls betwen objects must go 
through a kernel.  In my system calling code can be inlined into modules 
during compilation.

>    It's not a matter of what your kernel is like. The same problems stands
> for just *any* kernel. How can you build a kernel with no overhead ?

Inline the kernel code into modules.

>    As for security, you admitted yourself that it's a complex matter that
> can't be dealt with simply. How can a kernel enforce security ? It just
> cannot; it can fake security as under unix; but it cannot enforce it.

If each module must be entered at one point, then code at that point 
(module defined) can enforce any desired security.

>    *You* explain what you'll put in your kernel so you show how a kernel
> can provide fine-grained services (say down to integers), together with
> security, and still have no deadly overhead. For that I don't believe is
> possible. I've given plenty arguments for my thesis, whereas your
> only argument at this day has been prejudice aquired from self-claimed
> state-of-the-art technology fads (oops, no offence meant, but really,
> please give solid arguments).

As soon as I have my sample kernel ready, I'll show you how! :)

Mike