Fare's kernel definition

[Francois-Rene Rideau]

> All I'm saying is your kernel definition is too restrictive.
   So what do you call "kernel" ? Maybe we agree on ideas, but just not
on words. For instance, would you call "kernel" the __NEXT__ macro of
a threaded FORTH written in assembly ? E.g. "lodsw ; jmp ax" on a typical
8086 FORTH, or just a bit set in a specialized FORTH chip instruction.
You really seem to do, especially when you agree that kernel code should
be inlined in modules.
   Then, will you forbid any procedure that wouldn't use this __NEXT__
"kernel" to pass continuations ? If you do, do you not call that unneeded
overhead. And if you don't, why do you call it a "kernel" at all ?
If you do, then I agree that we will be providing a standard kernel,
while I still will argue that our kernel should not be an axiom, but an
implementation dependent *and* module dependent thing; so as it's module
dependent, I don't call it "kernel".


>>    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.
   I'm against anything that's compulsory; while still agreeing that we need
provide freely acceptable standards.


>>    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.
  See above about the __NEXT__ macro of a FORTH system. Do you call *that*
a kernel ?

>>    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.
   So you really seem to call that __NEXT__ macro a kernel. Again, does that
mean that all modules will have


>>    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.
   Then what is the kernel for ? Just calling another module ? Then yes,
it's pure overhead, because the modules could call each other directly. And
why have a unique way of invoking another module, when each module could have
its own efficient way to invoke or being invoked ? If you move the kernel to
the meta level, why also have some unique way to encode calling conventions ?
Different module families may be considerably faster with a specialized
meta-protocol.
   Now, as for security itself, why have only one entry point ? Why check
security at run-time ? Why not check it at compile time, or at link-time,
that is, as early as possible ? Doing so is only pure unnecessary overhead.
That's what I'm argueing.


>>    *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! :)
So what do you think of my FORTH "kernel" (__NEXT__) ?
Or you may choose the Scheme runtime system as a kernel, or /bin/sh.
What exactly is a kernel to you ?

--    ,        	                                ,           _ v    ~  ^  --
-- Fare -- rideau@clipper.ens.fr -- Francois-Rene Rideau -- +)ang-Vu Ban --
--                                      '                   / .          --
MOOSE project member. OSL developer.                      |   |   /
Dreams about The Universal (Distributed) Database.       --- --- //
Snail mail: 6, rue Augustin Thierry 75019 PARIS FRANCE   /|\ /|\ //
Phone: 033 1 42026735                                    /|\ /|\ /