Jump to content

Microkernel vs Macrokernel


1veedo

Recommended Posts

I just checked out an OS called Minix3 and I'm actually quite impressed. It sounds like what they're working on is a pretty good idea.

 

I'll be it, user space possesses normally run a little slower (l4Linux for example runs slower than the the Linux macrokernel), and codding a microkernel is a lot harder to do, but I think a fully functional microkernel might prove to be superior to a macrokernel. My bets are on GNU/Hurd, but people have been "betting on it" for more than 15 years now and I doubt there will be any great releases running the GNU/Linux API any time soon.

 

Tanenbaum (main developer for Minix) is the guy that had a flamewar with Linus in 1992. I don't know what happened to microkernels but in 1992 everybody seemed to agree they ran better than macrokernels (amigaos, for example). The wiki for microkernels seems to act like they're inherently slower but if you read it, it's more or less pointing out that it's just difficult to implement some of the theory for making them run faster.

 

I guess the reason macrokernels are so popular is because they're easier to program. Microsoft even seems to see the benefits of a microkernel, their move to NT was an attempt to do this but they managed to make Windows into some kind of in the middle half macro half micro. With Vista they're starting to see how big a mess Windows is and Microsoft is moving drivers to user space, hoping to fix some instability issues (while at the same time sacrificing speed).

 

There are some great microkernels out there, they're just usually used for embedded systems and either dont run much (as with Hurd) or on "mainstream hardware" (AMD/Intel).

Link to comment
Share on other sites

The most successful operating systems out there (NT, OS X, Linux) have all started from microkernel concepts and used them to build a macrokernel. While Linux merely borrows conceptually from a microkernel OS (Minix), NT and OS X are both derived directly from microkernel operating systems, and have since been refactored into macrokernels (although NT continues to capitalize on "services" which are somewhat similar to microkernel servers)

Link to comment
Share on other sites

Hm I'm pretty sure Linux has been monolithic from the beginning. Even in 1992 "Linux is obsolete," Linus says, "True, linux is monolithic, and I agree that microkernels are nicer." I think I read somewhere he ran minix to implement and make his kernel, but from the very beginning (and still today), Linus has disagreed with Tanenbaum, the creator of minix and one of the biggest supportors of microkernel theory, on OS fundamentals.

 

NT started as monolithic and Microsoft attempted to create a microkernel, with no avail, and still today they're actively heading in that direction. Like I said with drivers being run in user space for Windows Vista. Dos and the original Windows were both macrokernels.

 

Mac OS X though I forgot about. It runs the same GNU/hurd mach kernel underneath XNU. Technically speaking I think most people consider it macro but it did, as you say, have its roots in a microkernel.

 

Most things you read about microkernels seem to push the main theme that microkernels are more reliable, but slower. The sort of thesis for "Can We Make Operating Systems Reliable and Secure?" (Tanenbaum) is "Microkernels...might be making a comeback in operating systems

due to their potentially higher reliability, which many researchers now regard as more important than performance."

 

Maybe I'm just a noob but personally I think performance is more important than reliability. Not because I think it's better to be fast and unreliable than reliable and slow, but because there are already monolithic kernels that are extremely reliable (BSD and Linux for example). It's like saying microkernels are more reliable than highly reliable systems that never crash in the first place. That may be true but the statement becomes superfluous. If we found something wetter than water, does it really matter? On the outside both would seem just as wet, even if /technically/ one was wetter than the other. So when it comes to choosing between two operating systems, if both are highly reliable, a more important factor is performance: How fast it runs.

Link to comment
Share on other sites

Microkernels are already used in tasks that require absolute stability and performance - real-time operating systems such as those that run factory robots. The ability of a microkernel to recover from most failures by simply restarting the affected "server" beats anything monolithic kernels have to offer (besides being well-coded). If GNU/Hurd succeeds and becomes exceptionally stable, it will probably become popular for tasks such as servers where reliability is important.

 

Unfortunately, interprocess communication slows down microkernels a lot. Better techniques have lowered that overhead to about 5-10% (in the L4 microkernel), and things are getting better. I think we'll see new microkernels in a few years that have equal or better performance and higher reliability.

Link to comment
Share on other sites

Unfortunately GNU/Hurd is in rather a bad position at the moment. Firstly, the monolithic Linux kernel is proving to be exceptionally popular at the moment for desktop machines, making it rather a trendy thing for developers to work on. This, in turn, drives them away from other projects (such as GNU/Hurd) and hence the already slow development cycle becomes extremely slow indeed.

 

For example, I seem to remember a Gentoo GNU/Hurd development team. Unfortunately it suffered from the aforementioned problem, and is now rotting in a heap as I understand.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.