[openbeos] Re: BeOS a microkernel?
- From: Timothy Covell <timothy.covell@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx,Timothy Covell <timothy.covell@xxxxxxxxxxx>,"Manuel Jesus Petit de Gabriel" <freston@xxxxxxxxxxx>
- Date: Tue, 22 Jan 2002 00:23:14 -0600
On Monday 21 January 2002 23:14, Timothy Covell wrote:
> On Sunday 20 January 2002 22:14, Manuel Jesus Petit de Gabriel wrote:
> > > I know what he was saying.
> > > Is it now necessary to see the source to be able to argue if or not a
> > > design decision is the right one ? That's a new one to me.
> >
> > It's not necessary but helps a lot. Also most of those arguments against
> > BONE were not very sound. The only good one was the unstabilities in
> > the early versions... but it was usually accompained with rants about
> > how BONE was breaking the microkernel design of BeOS... and those
> > ranting about really did not know what they were talking about, since
> > BeOS is not a microkernel.
> >
> >
> > manuel,
> >
> > > Mark
>
> Perhaps you could explain why the preBONE kernel was not
> a microkernel? Certainly it is much closer to the microkernel
> side than the monolithic side. AFAIK, the kernel in R5 contains:
>
> o Memory Manager
> o Messaging Infrastructure
> o CPU recogintion but not MTRR
> o VFS
> o Entry points/glue for drivers and add-ons
>
>
> Also, by using the "bus manager" concept, it is certainly even
> more slim that it would be otherwise.
>
>
>
> That much said, I really like Kurt Skauen's reply about AtheOS:
>
> Q: What kind of architecture is the kernel built on? Monolitic,
> micro-kernel, nano-kernel?
>
> A: I often ask myself that question to :) The kernel is very modular and
> the it have a well defined interface between the kernel and it's
> device-drivers and file-systems. So given that each component communicate
> through a thin well defined interface, and don't know much else about each
> other, it ressembles a micro-kernel. I am not sure if this is the right
> term though, since all kernel-components lives in kernel-space and is not
> protected from each other, this is all properties from a monolitic-kernel.
> I am a bit confused :)
OK, here's a definition that I found on the internet:
The fundamental attribute that distinguishes monolithic vs. microkernel
vs.
exokernel architectures is what the architecture implements in kernel
space (that which runs in supervisor mode on the cpu) vs. what the
architecture implements in user space (that which runs in
non-supervisor mode on the cpu).
So, technically, BeOS is not a microkernel per this definition. However,
I'm not convinced yet that the term microkernel was this well defined from
the start. From what I can tell, it would appear that originally a
microkernel was "minimalized" kernel, but little distinction was made
concerning where it lived (I suppose only the Carnegie Mellon Univ.
folks could settle that question.)
Further confusion arises from the term monolithic, which litterally
means "one stone". Kernels like Linux were originally built as one image.
BeOS, on the other hand, is very modular. The move to modular kernels
make Linux and Solaris appear to be smaller, but they very much retain
their monolithic heritage. Indeed it's only in Linux 2.5 development that
discussion is being made concerning the driving of the stake through the
continued ability to compile single-image kernels.
A final confusing aspect is that BeOS has both kernel-mode
and user-mode drivers and servers, so BeOS blurs the lines. It very much
looks microkernel, but the default drivers are loaded into kernel space.
Like Kurt Skauen says, it is easy to get confused when talking about this
stuff.
--
timothy.covell@xxxxxxxxxxxx
Other related posts:
