[MPMoriarty]

I wasn't sure where to post this, but I figured this would be the best spot since this has more to do with the lower levels of Darwin.

I was chatting with a friend of mine the other day who is curious about Mac OS X. I of course was going over all the cool technology features and benefits that Mac OS X offers. So we got into discussing how Mac OS X's system kernel is based on Mach. I told him that Mach is very stable because of its efficient design and approach.

Here's what I said...

----------------

Mach is considered a microkernel.

It doesn't have all of the operating systems code and instructions stored inside the actual kernel itself. It only has a limited set of instructions for basic core operating system functionality.

Mach handles additional tasks through the use of kernel extensions. These are independent programs which connect to the main kernel and contain additional code and instructions for managing hardware.

The benefit of this efficient design comes from that if one of these kernel extensions should fail or quit unexpectedly, only it will go down. The rest of the operating system will be unaffected. These affected kernel extensions can simply be restarted independently.

This has a significant advantage over traditional monlithic kernels where all the code for an operating system is contained in the kernel itself. While this offers a speed advantage, it comes at a price in overall system stability. If code in the kernel has bugs or comes across problems, the entire system could can freeze up and even crash.

-------------

He said that doesn't sound right and that I better go do some research so I came here. Do I have my information backwards or is what I said pretty accurate.

Mike

[Gavin]

Prety close.

Mach is not considered a microkernel. It is a microkernel.

It splits the low level OS into 2 parts,

Mach is the part of the system that talks to the CPU. It is responsible for putting code on the processor. That's about it. It handles 'threads' and 'processes'. It also handles the things that make OS X so stable like protected memory and Multitasking. As in each program gets its own area of memory and can't overwrite another program's data, especially important for the system. Also, each program gets a few micro seconds to run on the CPU then it gets pulled off and the next program gets its turn. It goes fast enough that every program seems to be running at the same time. Mach handles the scheduling of that.

Linux basically does the same thing but it is all built into one big kernel.

The main advantage to Mach is portability - you can get your OS running on a new processor by changing Mach not the whole kernel. You can also run different OSes on top of it (at the same time even) There was a version of linux called mkLinux that ran on top of Mach. So apple was able to alter BSD to run on top of Mach, which already runs on the PPC chip and is has a track record because of Next which also ran on Mach and the PPC


Here's an overview:

http://developer.apple.com/documenta...H207-TPXREF101

[MPMoriarty]

Ok, so let me see if I got this straight.

So Mach only handles scheduling processes on the CPU and RAM, right?

What do the kernel extensions handle?

Mike

[Kristoff]

Originally posted by MPMoriarty:


What do the kernel extensions handle?

Mike

File I/O, Networking, Sound, Video, USB, Firewire, Bluetooth, etc etc etc

drop to your terminal and do a:

locate kext

to get a list of them.

[JNI]

So the OP's descriptions seem pretty much on target to describe the architectural differences. But can someone describe some real practical differences?

The description says that there is less code in a mik's protected space. That would seem that the kernel should be smaller in Mach systems, no? My mach_kernel shows as being about 3M, where as my vmlinuz shows as only being about 650k. What's up with that? Is it because the Linux kernel links to external libs that are then loaded into the kernel's memory space, whereas in Mach loaded kexts are not? So the runtime footprint for the kernel should be smaller in a mik. Can that be shown?

If fewer mid-level services are running in a mik it theoretically should crash less often than the mok of Linux. Has that been shown to be true? I've gotten a few kernel panics on my Mac, but only about 5 times in the last four or so years.

Also, if many more mid-level services are built into a mok, then adding or modifying services there means possibly rebuilding and distributing a new kernel, right? But if they are in externally loaded libs, that seems like it wouldn't always be the case. What are some examples in Linux where additions or updates require a rebuilding of the kernel where that isn't the case in Mach? E.g. if you wanted to add a new USB driver in Linux, does that require rebuilding the kernel, whereas that isn't the case in Mach? Would that mean that it is easier for a third-party to add services to a mik, whereas in a mok they may actually have to distribute a new kernel?

For all practical purposes in the Mac world, most people don't care about the architecture. They care about the real world implications. So I'm just looking for real world dis/advantages of each architecture.

[Gavin]

First remember that the kernel sits on the Mach microkernel.
The extensions add functionality to the kernel not the mircokernel.

Both Linux and OSX can dynamically load extensions to the kernel.

You can also build them in, because there is no interface code to get in the way it's faster. That makes sense for things that get a lot of use. For instance, on my linux server I hardly ever plug in a keyboard but it is always online, so I have the ethernet card driver built in but the USB driver as a module. I had to recompile the kernel to do it.

So yes, you can add modules to linux without recompiling the kernel, that's what module are all about. You don't even need to restart the computer to load the module in. Or you can recompile it to add stuff in or strip stuff out, like I will never hook up an NTFS filesystem so I took that part out, several other things too.

Of course the more stuff you compile in the bigger it gets. With the mac on the other hand I'm sure apple rolls in everything.

With smaller discrete pieces, like a mircokernel or kernel modules, it is easier to find the bugs and to optimize things. You can know exactly what Mach is doing to the CPU without worrying about some latent effect from the ethernet driver. And it is harder for bugs in one part to cause problems in another. The trade off is that there is extra code to allow the pieces to talk to each other so it slows the whole thing down a little, everything involves an extra step.

[MPMoriarty]

I am confused now. Are you saying there are two kernels now.

The Mach microkernel and Mac OS X's kernel?

I thought that at the center of everything was the Mach kernel (Mac OS X calls its implementation XNU). Then Mach's functionality is extended by connecting to kernel extensions which have the instructions to talk to other hardware on the system.

So I am incorrect?

Mike

[Gavin]

It not microkernel as in an abnormally tiny kernel , it's microkernel as in a small piece of the bigger kernel.

Here's apple's desription
"The Mac_OS_X kernel is the fundamental layer of the Mac_OS_X operating system. This environment includes the I/O Kit, the Mach kernel, and a BSD personality layer."

http://developer.apple.com/documenta...rnel-date.html

So you can see we're talking about 2 things. Mach is one part, the Kernel is another. Part of the problem is that everybody mixes their terms, even among the tech docs. Sometimes all the low level darwin stuff is "the Kernel" sometimes just Mach is "The Kernel".

IN OSX the base system is made of several parts.

Mach Microkernel - sometimes simply called the Mach Kernel just to confuse people, CPU related stuff. Everything else runs on top of Mach.

BSD - it handles POSIX, permissions, users, etc.

IO kit - peripheral drivers, USB, etc

Filesystems- hard drive, cdrom etc.

Networking..

a couple more I think

All of these together are the Darwin Kernel and is similar to the the Linux Kernel, which just puts all the functionality in one big piece, which is why they call it "monolithic".


Here's something I found that lists some of the benefits of Mach and microkernels in general.

http://www.cbbrowne.com/info/microkernel.html


Here's a lot more than I know about the structure of OSX:
http://developer.apple.com/documenta...H207-TPXREF101

which is part of this:
http://developer.apple.com/documenta...iew/index.html

[MPMoriarty]

Ah I see.

[MPMoriarty]

Ok so let me see if I got the facts down now.

- The Mac OS X kernel is based on a microkernel architecture because it is made up of independent components all working together.

- The Mach microkernel is one of these components whose job is mainly to manage memory and handle CPU processes.

- Mach is the heart of the Mac OS X kernel.

- Everything else in the kernel (I/O kit, BSD subsystem, etc.) runs on top of Mach.

Is this pretty correct?

Mike

P.S. Thanks again for clearing up a lot of information on this subject. I am learning a lot of stuff I didn't know.

[menglish]

The key difference between a micro-kernel and a monolithic kernel is how many different services get to run in "kernel" mode or "protected" mode (giving the running process all privileges on the system).

In a micro-kernel very little code gets to run with these privileges, just the basic services. Those being message passing, interrupt handling, process scheduling and maybe some I/O (I'm not an expert, so don't take that as a definitive list). The rest of the OS services run in user mode (with the privileges "the rest of us" get).

In a monolithic kernel all of the OS services run in protected mode, including the file system, memory managment, etc...

The advantage of a micro-kernel is that your really important stuff is small and streamlined, and very unlikely to ever crash. Nothing but those very select services can bring down your kernel. On the other hand, the drawback is that the OS services that are running as user processes must make system calls (and thus context switches) all the time in order to perform it's basic functions (message passing between user processes requires some kind of kernel help...hence a context switch or two). This makes a micro-kernel theoretically slower than a monolithic kernel.

From my perspective the elegance of design in a micro-kernel is much better than a monolithic kernel. And aparently the slowdown caused by message passing has been a target of quite a bit of research and optimization, and has been reduced to a very minimal, if non-existent issue lately.

[Gavin]

Originally posted by MPMoriarty:
Ok so let me see if I got the facts down now.

...

I think he's got it!

P.S. Thanks again for clearing up a lot of information on this subject. I am learning a lot of stuff I didn't know.

Sure, glad I could help.

There is a price though...

You have to explain it to the next guy.