Fare's kernel definition

[Francois-Rene Rideau]

> 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.

   You don't seem to have understood my messages. Please re-read them.
I defined a kernel a syscall manager, some service provider that hides
behind a static system call convention. Indeed, if it was dynamic, it'd
mean the system is dynamic also, so how could it be called a kernel ?
Or would you call the dynamic linker a kernel ? But why should it be
static ?
   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, whereas I use mine.

   Now, with this definition of a kernel, the problem with kernels is
that a kernel is some compulsory interface between objects; any
functionality (including security) it has does not bring anything as
compared to these functionalities being provided by separate modules,
but instead make monolithic hugeware out of the kernel. And the
non-functionality part, the arbitrary calling convention, is pure overhead.
   Directly linked objects are *always* faster than objects that communicate
through a kernel. If the kernel message passing (including the both sides
of message passing) is say 200 cycles long, any object for which 200 cycles
is not negligible won't be able to be an efficient kernel-aware object.
Which means you'll have to build a system on top of your kernel to deal with
those tiny objects anyway (and let me remind you that human being mostly
deal with such tiny objects that they fully understand). So your kernel is
just some bulky overhead for the over-system.
   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 ? The
more functionality you add, the more overhead also. The "kernel" with the
smallest overhead is the NEXT macro in a FORTH system, but as you see, it's
also inlined in actual words...
   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.

   *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).