[gioele]

> Micro kernels are very hard to debug.

Microkernels are not harder to debug than monolithic kernels. I'd even say that they are easier to debug, much easier. (Personal experience in debugging both.)

The problem with microkernel-based OSes is, as Linus Torvarlds aptly put it, that they turn well understood memory-protection problems into not-so-well-studied IPC problems. (The actual quote is «They push the problem space into communication, which is actually a much bigger and fundamental problem than the small problem they are purporting to fix.»)

The microkernel is not the real problem here, the big issue is debugging faulty IPC sequences between the servers that implement the OS services. A problem that is almost non-existent in monolithic kernel.

HOWEVER, current monolithic kernels are facing growth problems now because of two aspect: we want fancy remote storage accessed as easily as local storage (do you want to mmap a file stored in a RAID setup implemented with SATA-over-ethernet disks?) and the fact that the process model is too leaky and so we need stronger containers like VMs (that are becoming as much leaky abstractions as the current processes). All these new features require communication between various components that were previously though and implemented as independent. This means that the IPC problems are now creeping into the world of monolithic kernels.

[kabdib]

There were a number of microkernel efforts at Apple in the 80s and 90s.

- Pink (later known as the money-burning party Taligent) had a 'new kernel' that was message-passing. They spent a lot of time working on RPC efficiency.

- The Newton used a message-passing kernel. Not the most efficient thing in the world, but there was MMU support to do some interesting page sharing / fault dispatch policy stuff, so you could get IPC-like behavior with faults. Basically hobbled by a 20Mhz processor with minimal cache, and not very much RAM at all.

Btw, I didn't notice the Newton being very hard to debug (except that all of our debugging was printf, or you stared at the disassembled output of CFront).

[zanny]

The way you word it, (and from my personal bias) it seems like people kicked the can on getting IPC right down the road. I like how plan9 handled it - one socket layer to rule them all, call into other programs over sockets, and let the filesystem handle the translations. I think in this modern era of extreme hardware juice, this could easily work. And work better than what we have.

Then again, I think shared memory is a harder problem to solve than using IPC through some buffered file metric. The synchronization becomes a pain in the butt, even if you manage a smidgen more performance out of the ordeal, it isn't very reusable, so it is only a situational tool. I feel like module injection a la Linux should have been a situational tool as well (at best), but we ended up putting everything in the kernel, and we keep adding more (KMS, KVM, DMI2, etc).