Andy Tanenbaum Releases Minix 3

Guillaume Pierre writes "Andy Tanenbaum announced the availability of the next version of the Minix operating system. "MINIX 3 is a new open-source operating system designed to be highly reliable and secure. This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code. The parts that run in user mode are divided into small modules, well insulated from one another. For example, each device driver runs as a separate user-mode process so a bug in a driver (by far the biggest source of bugs in any operating system), cannot bring down the entire OS. In fact, most of the time when a driver crashes it is automatically replaced without requiring any user intervention, without requiring rebooting, and without affecting running programs. These features, the tiny amount of kernel code, and other aspects greatly enhance system reliability."In case anyone wonders: yes, he still thinks that micro-kernels are more reliable than monolithic kernels ;-) Disclaimer: I am the chief architect of Globule, the experimental content-distribution network used to host www.minix3.org."

Comments

Re:Tanenbaum gets a failing grade

[Salamander]

It's not the microkernel that's a bad idea

I hope you have a good rear-view mirror while you backpedal.

it's the C/asm implementation and using separate address spaces that necessarily follow from that

...except that they don't. Microkernels have been implemented in other languages, and it has already pointed out to you that they have been implemented in single address spaces.

Drivers usually take more code since they often have large tables in the code

...and you base that statement on...what? It's no more true of drivers than the rest of the kernel. You also fail to note that almost everything under fs/ and most of net/ is really driver code too.

I'd say it's a pretty safe bet that the vast majority of the code in a running kernel is not drivers.

By your own count, which is flawed, over 70% of the code is drivers. By a more realistic count it's likely to be 85-90%. Many would say that's the real metric of code size, since that's what has to be debugged and accounted for in designs. It's true that the percentage of code loaded into any given instance of the kernel is likely to be lower, but that actually highlights an interesting point: loadable modules represent an evolution toward microkernel ideas. In the Bad Old Days vendors shipped truly monolithic generic kernels, and then users would configure and relink for the devices they had. I don't recall offhand whether Linux was originally that way, but I think it was and I know for sure that BSD was. Even though they're loaded into a common address space, loadable drivers are very much a microkernel idea. Even process and I/O schedulers can be loaded nowadays, which moves us further in that direction (leaving little but the VM system). Now that they're widely adopted the majority of code that's loaded might not be drivers, but it's still not a vast majority and the majority of instructions during any given time quantum might well be drivers of one kind of another. By two out of three metrics - written, loaded, run - drivers are the majority of code. It's lovely that you could write a script to count lines, but it would be even better if you could understand the numbers you were looking at before you make more false claims.