a no-kernel system
Tue, 20 Dec 94 2:28:33 MET
[Here is a message about my vision about an operating system without a
kernel -- beware ! This does not mean no piece of software may have a
kernel; but that no piece of software is compulsory]
Why I'm against any kind of OS "kernel"
What is an OS ? It is a basic set of standard software services, that
programs may rely upon. What is a kernel ? It is some centralized piece of
software that is called each time a service is needed by some software
Now what does such kernel mean ? It means that just *any* communication
between different system objects must go through the overhead of a kernel
system call (aka syscall). Which is some much too large overhead for small
to tiny objects. Thus, for efficiency reasons, such small objects won't be
implemented as separate system objects, but as subobjects of some common
system object (commonly called "process"). Now, the processes must implement
all the logic to manage the small objects; and they may even have to
implement all the necessary communication package to pass these objects
through the system to other system objects; that is, those process will
have to reimplement a better system on top of the OS. Processes must also
ensure themselves the integrity of smaller objects and all kind of access
So indeed, the kernel design only brings some useless burden with
limited functionality, and requiring processes to provide security and
services themselves. We end up with a no-system, which at best is a
collection of device drivers with a weird slow interface.
Reducing the kernel size (the current trend for "micro-kernel" only
decreases kernel functionality and explicitly moves responsibilities to
"users"; but it does not solve anything and kernel is ultimately reduced
to pure overhead.
That's why I'm against any kind of kernel. Let's provide services,
but without any kernel. Let's be completely modular. How can it be ?
By dynamically linking objects directly each to the other and not
requiring them to pass control to some central dispatcher that only
wastes space and time. Moreover, such method allows linked objects to
communicate directly, with no intermediate, thus eliminating loss of
performance due to passing messages through a kernel. Now how about
security ? Well, it's up to the dynamic linker to ensure security, by
linking together only willing objects that can understand each other,
and that fulfill each other's conditions. We'll then say that the
objects use the same protocol, and the way the dynamic linker
recognizes what object protocols will be called the (well, a)
meta-protocol. Actually, much more adapted security is thus made
possible than could ever be dreamt of with a kernel.
But then, some will argue, the dynamic linker is the actual kernel !
No, because the dynamic linker is itself some dynamically linked and
replaceable object, and need not be unique or constant, so anyone can
use whatever dynamic linker he finds (and is able to use); just being
intensively used will no more make a kernel out of the standard
dynamic linker than it will have made one out of the keyboard driver,
or of the printf (or equivalent) routine.
As for standard objects delivered together with the OS, they are not
kernels any more than the dynamic linker. They are only that -- standard
objects. Nobody is *forced* to use them, and third parties may well provide
better versions for them, or incompatible versions also; people will use
whatever object seem the best for them, and the best will eventually prevail;
so we will not be forcing people to use our standard objects, but instead
we are suggesting people to use the objects we designed the best for them,
and we will succeed if and only if we actually provide the best objects.
This is concurrency and natural selection in a free computing world.
For What did we end up with ? A world of computing *freedom* indeed,
where objects are free to interact; and freedom not meaning anarchy, as
there are regulators, the meta-protocols, that ensure that no object
is used in despise of its rights, and that all objects respect their
duties, which is better than any kind of bitmap-based security
checking. Trivial objects will have trivial security checking, with
no overhead from such bitmap test, while complex objects will have
full-fledge security checking, with strong typing and perhaps program
correctness proof, and no security hole from over-simple bitmap test.
Without kernel, all objects are able to talk directly each to the
other, and communicate freely.
This does not mean one won't be able to write kernel-based
software; any kind of programming is accepted, and if kernels are
useful for something, they sure should and will be used for that.
-- , , _ v ~ ^ --
-- Fare -- firstname.lastname@example.org -- 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 /|\ /|\ /