What is a kernel?

Thomas M. Farrelly s720@ii.uib.no
Tue, 17 Aug 1999 12:41:42 +0200

I've been reading the 'microkernel' thread and I am a tad bit puzzled.

Is Farč really pro monolithic kernel design? Possibly. He is definitely
carrying pro arguments.

I understand the reason a monolithic kernel would be easier to make
efficient. This is because more things can be assumed, which in turn can
be statically determined. The reason
more things can be assumed is that when all the kernel stash is in one
big object ( not literally ), many of the critical operations of the
kernel can be "private". So you don't have to worry about keeping a
consistent state all the time, because nothing else could
tap in and observe.

In a micro kernel, the communication between application and kernel is
more intense - and the kernel has little apriori knowledge about the
application, so it has to behave according to strict patterns and rules.
In other words a kind of bureaucracy, which in it
self demands resources.

One important point in TUNES is fine grain modularity. I don't see how a
monolithic kernel could be fine grained. Wouldn't that be no kernel at
all, or even, dependent on our definition of kernel, a micro kernel with
some framework added.

But techincally you could have the efficiency of a huge static chunk of
program with the modularity of a micro kernel design. Because there are
ways to determine static dependecies and recompile parts of a program.
But that's another thread.

Two stupid questions:

What if you had a monolithic kernel and wanted to make it into a micro
kernel. You start by cutting things from the kernel and pasting them
into their own objects or files. The objects you are creating form the

As the kernel gets smaller the framework gets bigger. At some point you
have a micro kernel with a framework.

What if you continue decompositioning the kernel - what would you end up
( Remember that a kernel is not just a system but a program wich
initiates the system -
a bootcode. If this is all wrong, then search-erase 'bootcode' from here
	A bootcode + a modularized monolithic kernel
	B bootcode + a framework
	C an even smaller kernel

The question is really: Isn't 'bootcode' the only part of the kernel
which cannot be put in the so called framework?

I know this is naive to think because there are other lowlevel things,
like threads and processes, interrupts and hardware, which cannot easily
be conseptualized in a way that lets you put them in the framework.

And this is basically question number two:

Which of the following does not fit in a microkernel:
	I/O		processes
	bootcode	ADT's
	GUI		the stack
	the heap	security
	memory management ( GC )
	networking	minesweeper

    Thomas M.  Farrelly     s720@ii.uib.no     www.lstud.ii.uib.no/~s720