Haiku Kernel Architecture Questions

I can’t seem to find any in-depth documentation on the Haiku kernel, other than that it was forked from NewOS and that it is very BeOS like. I am interested in how the kernel differs from the BeOS kernel and other kernels in general. I know that the network stack in integrated in the kernel, but do the other servers still run in user space? I have read that the BeOS kernel was not a real microkernel in the sense that some drivers ran in the kernel, is this the same with the Haiku kernel? How does the Haiku kernel perform compared to BeOS or a monolithic kernel like Linux or the BSD kernels?

If any of you guys could point me in the direction of some documentation that answers these questions it would be much appreciated.

I’d like references to come to speed on Haiku kernel, so I may eventually contrib towards deploying to ARM. I see tablet form-factor inheriting from desktop PCs rather than smart-phone-cum-PDAs. As BeOS was about more about PC than connected phones, and Intel Architectures are headed more towards CISC: that’s great work with data-centers hosting clouds than the battery operated hand-held ARM (RISC) tablet, so I’m eager to see Haiku target this form-factor gaining wide acceptance. Windows already has appstore+WinRT to build marketshare here, besides the Phone segment, that includes .net micro & Java4 mobile & Google Android. And iPad running MacOSX rather than iOS shouldn’t be surprising.

I’m not sure there’s a lot of documentation on the kernel itself. I think it is expected that if you are interested in the kernel you might want to go straight to the source code:

Haiku is a monolithic kernel with loadable modules, just like Linux. The “servers” (I guess you’re referring to the app_server, input_server, etc.) are not to be confused with the servers from a microkernel architecture like Minix.

I don’t know any highlevel docs on the Haiku kernel either, but then compared to Linux the amount of source code is rather manageable. It’s pretty well readable, too. If you end up going down that road you might do the community a favor if you write some doc on the way. :wink:

Would you care to elaborate on that? Because, to my knowledge, the size of the Haiku kernel is a fraction of the Linux kernel. And the Haiku servers look and smell like those in Minix. Feel free to reference source code.

To my knowledge, and I haven’t looked at the kernel source because I code at the app level, BeOS was a true micro-kernel, Haiku is a ‘hybrid micro-kernel’ because the drivers are monolithic and live in the kernel, not user land. Other than that, the Haiku kernel has most of the attributes of a microkernel. Correct me if I am wrong.

And BTW, we love to argue about microkernels :slight_smile:

And yes, if you wanted to add some documentation it would be greatly appreciated.

Neither one is even remotely a microkernel by any definition. A true microkernel has very little running in the kernel itself besides thread management and virtual memory management, i.e. even device drivers live at the userland privilege level. Both BeOS and Haiku have all kinds of other modules and subsystems in kernel space, which rules them out of the microkernel qualification entirely. I might further note, source code size is completely irrelevant to whether or not something is qualified as a microkernel.

Actual kernel size has little to do with whether it’s monolithic or microkernel.

It has far more to do with process and memory separation…

When a driver loaded by the kernel can crash the kernel, it’s monolithic. When a crash in the netstack or its drivers can crash the kernel, it’s monolithic. When a misbehaving video driver can crash the kernel, it’s monolithic (the use of accelerants makes this particular example a hybrid).

In a true microkernel system, almost nothing is running in the kernel’s process space, and therefore, none of the drivers, network subsystems, etc. can crash the kernel or access it’s memory directly.

P.S. As a side effect, microkernel’s are expected to be slower - there’s a lot more overhead, and message passing involved.

They’re really nothing at all alike.

Let’s take as our first example a Minix File Server. In Minix a File Server is a process which implements one of the disk filesystems, for example FAT. It runs in userspace, and it receives messages from the VFS server and sends replies back. Most File Servers in turn send messages to servers providing access to the physical disk hardware. If the file system crashes, Minix tries to restart it and if that’s not possible you are no longer able to access files from that server but the rest of the system continues to function.

In Haiku there is instead a piece of kernel code, a filesystem driver which implements a disk filesystem. It runs as part of the Haiku kernel (you can see source code in haiku/src/add-ons/kernel/file_systems/fat) and other code in the Haiku kernel can make function calls to it, and access its data structures directly and it can do likewise. If it crashes the kernel has crashed, you will get a KDL prompt at best or perhaps the machine will just lock up and you’ll have to restart.

BeOS was the same in these respects, the only place where BeOS resembled a microkernel design at all was in the decision to put the network stack (TCP/IP implementation, etc.) in a userspace program called net_server. But the actual network hardware drivers lived in the kernel just like any other monolithic kernel. The net_server design can perhaps mostly be explained by timing, BeOS marginally pre-dates widespread enthusiasm for the Internet and so adding Berkeley Sockets support to BeOS was probably just as much of a retro-fit as it was in Windows 3.x. As a consequence the performance is poor (Haiku network performance isn’t good, but BeOS was immediately noticeable for its poor networking) and interoperability is even worse than usual. If JLG had somehow known, in 1991, that the Internet was going to be huge in the next few years probably net_server would never have happened at all.

You suggest that Haiku’s kernel has “most of the attributes” of a microkernel. Perhaps it does, in the same way that a goose has “most of the attributes” of a fish. A goose and a fish are both vertebrates, and the Haiku kernel and a microkernel are both computer software. But I suggest a better test would be whether it has most (or indeed any) of the attributes that set microkernels apart from monolithic designs. A good start to answering that question would be to add to the list of such attributes. So far we have: drivers live in userspace, on which you agree Haiku fails.