[openbeos] Re: Architecture

>"David A. Rogers" <darogers@xxxxxxxxxxxxx> wrote:
>> I'm a little confused about the overall architecture of OBOS.  I'm 
>> looking
>> at the architecture graphic in the OReilly book.  Hardware on the 
>> bottom.
>> Microkernel above that.  Servers above that.  Software Kits talk to
>> servers and microkernel.  Applications on top.
>> 
>> Where do drivers fit in this picture?  When writing drivers for OBOS, 
>> are
>> they OBOS drivers or NewOS drivers?
>
>(I'll take a shot at this.. Feel free to correct me)

Actually, this is true AFAICT. Just a little more added data...

>I think BeOS may have started as a true microkernel,
>before the PowerPC and x86 releases.
>Perhaps Marco Nelissen can shed some light on that.
>It was a great buzzword. Be used it in their marketing,
>but I'm not sure there is a clear definition of what it really is.

As far back as DR8 (1996), it was not a micro-kernel by the classic definition. 
Really, that is a Good Thing. There has never been a really good microkernel, 
IMHO. Packaging up messages and sending them takes time, by definition. Time is 
the one thing that you don't really want to waste, in a kernel. Function calls 
are fast - that is why monolithic kernels tend to be faster and used more, IMHO.

Of course, having said that, add-ons have most of the advantages of both micro 
and mono kernels. That is why it is the BeOS Way - the sweet spot on the price 
performance curve, as JLG used to say.

>The NewOS kernel and the OBOS adaptation of it 
>is not a microkernel in the QNX or Mach sense.
>Neither is it monolithic.

Eh. Depends. Monolithic from the POV that all kernel code is in the same 
address space and "knows about" each other part is one way to describe BeOS. 
Monolithic taken to mean "everything is compiled into the kernel; if you want 
to add a device, rebuild your kernel" is, I think, a little bit of a stretch of 
the normal definition.

>Our device drivers run in kernel-space.
>They're loaded on demand, and unloaded when not in use.
>
>(Video drivers are loaded by the app_server though,
>similar to how X works in Unix.)

Yes to both, with the exception of accelerants. Accelerants are something of a 
hack - they let user processes call kernel code "directly". They are not safe, 
but they are fast.

>OBOS uses the NewOS kernel to replace the original
>BeOS kernel. NewOS was not a perfect match, but still 
>close enough. The kernel team is working on making 
>it more BeOS-like, so that we maintain binary 
>compatibility with BeOS R5 applications. A fork was 
>necessary to avoid forcing these changes on the 
>NewOS project.

Yes. 

>As the kernels of OpenBeOS and NewOS are drifting apart  
>(AFAIK) our drivers must be considered simply BeOS drivers,
>or whatever the new name of OBOS will be.. 

And, likewise, all BeOS drivers *should* work without changes or recompilation 
with OBOS, or whatever the new name is. ;-)

Other related posts: