Slashdot Log In
Get To Know Mach, the Kernel of Mac OS X
Posted by
Hemos
on Mon May 16, 2005 09:37 AM
from the getting-to-know-all-about-you dept.
from the getting-to-know-all-about-you dept.
An anonymous reader writes "Linux is a kernel, not an operating system. So what is Mac OS X's kernel? The Mach microkernel. The debate around Monolithic (Linux) and Micro (Mach) kernels continues, and there is a great chapter online about the Mach system from the very good book 'Operating System Concepts'. Which design is better? I report, you decide." Warning: link is to a PDF.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
This is a tough fight (Score:4, Funny)
They have more in common than you may think... (Score:5, Informative)
XNU is essentially a monolithic kernel, much like Linux. The real differences, in my opinion, lie in the IOKit object oriented driver API, whereas Linux has no real driver API and drivers have complete access to all kernel functions as drivers are simply kernel modules.
Parent
commence the horse beating (Score:5, Funny)
Re:commence the horse beating (Score:5, Funny)
Parent
Re:commence the horse beating (Score:5, Funny)
--
Evan
Parent
Re:commence the horse beating (Score:5, Funny)
No, take my pants off and you have the world's finest lady-pleasuring device.
Trust me, it works.
Parent
Re:commence the horse beating (Score:5, Funny)
--
Evan
Parent
MirrorDot (Score:4, Informative)
Complete Book reference (Score:5, Informative)
There are also free online chapters for FreeBSD and Nachos.
Link to Wiley's purchase page (given that we are
Ahhh!! Nachos!!! (Score:4, Funny)
Parent
design is better, performance is worse (Score:5, Interesting)
Re:qnx does just fine with a u-kernel and message (Score:5, Interesting)
In this day and age, there is no reason to use a macrokernel unless your hardware lacks the features needed for a microkernel. QNX has proved this quite nicely.
Parent
Re:qnx does just fine with a u-kernel and message (Score:5, Informative)
So does Mach, and it's slow. I've never seen real-world measures to suggest that QnX is fast. All we know is that the performance of the OS itself is good, and that's a VERY DIFFERENT measure.
The slow performance is due to a number of problems:
1) not all MMU's are really suited to this task. Many are slower to set up than just copying the memory around. Sun found this to be at around 5k, below that, it was faster to just copy memory physically.
2) MMUs/VM are based on pages, 2 or 4k typically. Thus passing in a single 32-bit int parameter causes big page hits. You can tune this out, but it's still annoying.
3) Each copy takes TWO context switches - one to switch into the kernel to copy the memory across ports, another back out to the called program. This means that even the simplest "system calls" are twice as slow as under a monokernel, AT BEST.
4) Additionally the data has to be examined to see if it contains ports being passed around, and if so, they have to be translated because the port codes are private to a program (and thus different in the other one).
5) Using mapped memory ignores all the hardware specific solutions to these problems, many of which are built into modern processors.
It's exactly the sort of one-size-fits-all solution that you'd expect from a research project. One that doesn't work in the real world. One that should have been replaced, and was in L4, Spring, etc.
For instance, Spring included three different IPC systems, each tuned to certain types of data, each used in different ways on different CPUs. The "fast-path" used a half-switch into the kernel by mapping off registers, allowing IPC to degenerate into register passing largely identical to a procedure call. As long as the message fit within the limitations -- 8 registers, no port identifiers, etc. -- it was faster than a traditional Unix trap. These limitations seem serious, but were in fact used for 80% of calls and 60% of returns (you often say "getDiskSector(integer value)" which could fit into the fast-path, and get back 2k of data which wouldn't).
Maury
Parent
Why warn us? Super Slashdot Effect (Score:5, Funny)
Um, if you want to warn anyone maybe you should warn the sys admin of the server that hosts the PDF file that you just put a link to on the main page of slashdot. I think they'll care a little more about the super slashdot effect (I'm coining that term for when a non-html file is linked to from slashdot - be it pdf, mpg, avi, etc.) than we will about taking the extra time to load.
Re:Why warn us? Super Slashdot Effect (Score:4, Insightful)
Parent
As always... (Score:5, Insightful)
Each system has benefits... but they almost always rely on the existence of certain assumptions.
Here's an idea for some news - (Score:4, Funny)
Smucks.
mach inject (Score:5, Informative)
Mac OS X is Mach, but it is not a Microkernel (Score:5, Interesting)
So, even though it uses Mach, you can't call it a Microkernel.
Re:Mac OS X is Mach, but it is not a Microkernel (Score:5, Interesting)
I suspect this is exactly how to never violate the microkernel design and still have BSD compat.
Parent
Re:Mac OS X is Mach, but it is not a Microkernel (Score:5, Informative)
Parent
Re:Mac OS X is Mach, but it is not a Microkernel (Score:5, Informative)
1. Mach is not a complete kernel. It requires someone to implement the areas which the Mach group were not researching. This has traditionally been done by compiling against BSD 4.3.
2. Mac OS X updated to the FreeBSD kernel instead of BSD 4.3 to gain a more modern kernel design with better hardware support.
3. OS 9 "Classic" is not a microkernel server, but rather a technology that Apple calls "Blue Box". Blue Box is a hardware virtualizer like VMWare that is capable of communicating directly with the OS X desktop. Using this communication, the OS 9 desktop is made to disappear, making the application appear to run on the OS X desktop.
4. The combination of Mach and FreeBSD is called "XNU" by Apple. The complete os is called Darwin, and the commercial variety with the Next and Mac APIs is called "Mac OS X".
More Info:
Mach Kernel [cmu.edu]
Wikipedia: Mach [wikipedia.org]
Wikipedia: XNU [wikipedia.org]
Blue Box info [kernelthread.com]
Parent
Linux the OS that is not an OS? (Score:4, Informative)
Google's definition of Linux [google.com]
I think you have more of a chance to start a discussion on that statement then you do in regards to which kernel is "better".
Linux IS an OS, both historically and now (Score:5, Informative)
That is a true statement for the GNU project, but not for all of Linuxdom. Linux (the OS) was not started by the GNU folks. It was started as a separate project and incorporated items from the FSF (and BSD, etc.) into its release. From the beginning the whole OS has always been called "Linux" (search Google Groups for "linux 0.11 author:torvalds" and click on the "Linux information sheet" for an example of this).
Yes, RMS prefers to call the OS GNU/Linux, but that's because he's seeing things from the perspective of the GNU project incorporating the Linux kernel into their work. The rest of Linuxdom see Linux as the name of both the OS and the kernel, and qualify the name using the phrase "the Linux kernel" as an easy way to differentiate between the two.
So, the opening statement in the OS X story is false: Linux is an OS, and is used as such by folks every day. This is the reality of the situation, and it is, at best, wishful thinking on the part of folks who claim it is not to say otherwise.
Parent
Re:Linux the OS that is not an OS? (Score:5, Informative)
Not so. Here a posting from Linux Torvalds about Linux -- from the beginning the term was used as both the name for the kernel and the whole OS:
LINUX INFORMATION SHEET
(last updated 13 Dec 1991)
1. WHAT IS LINUX 0.11
LINUX 0.11 is a freely distributable UNIX clone. It implements a
subset of System V and POSIX functionality. LINUX has been written
from scratch, and therefore does not contain any AT&T or MINIX
code--not in the kernel, the compiler, the utilities, or the libraries.
For this reason it can be made available with the complete source code
via anonymous FTP. LINUX runs only on 386/486 AT-bus machines; porting
to non-Intel architectures is likely to be difficult, as the kernel
makes extensive use of 386 memory management and task primitives.
[...]
2. LINUX features
- System call compatible with a subset of System V and POSIX
- Full multiprogramming (multiple programs can run at once)
- Memory paging with copy-on-write
- Demand loading of executables
- Page sharing of executables
- ANSI compliant C compiler (gcc)
- A complete set of compiler writing tools
(bison as yacc-replacement, flex as lex replacement)
- The GNU 'Bourne again' shell (bash)
- Micro emacs
- most utilities you need for development
(cat, cp, kermit, ls, make, etc.)
- Over 200 library procedures (atoi, fork, malloc, read, stdio, etc.)
- Currently 4 national keyboards: Finnish/US/German/French
- Full source code (in C) for the OS is freely distributable
- [...]
Parent
Xnu, not mach (Score:5, Informative)
stop spreading the myth that Xnu is a microkernel
Not a "compatibility layer" (Score:5, Interesting)
It's not just a "compatibility layer". A Mach system consists of multiple servers providing services to each other and to applications. The BSD server in XNU is an essential part of the system... it's the ringleader, and calls the shots from boot onwards.
Parent
Great OS Book - but what's Steve up to now? (Score:5, Funny)
So... does anyone here know what Steve Jobs and Mach have been up to since their halcyon days at NeXT?
Mac != Mach (Score:4, Interesting)
This approach doesn't make much logical sense to me, but it's what Steve and Avie wanted, and somehow, amazingly, it still just plain works.
mach vs posix (Score:5, Informative)
Given this compatibility effort, mach is not a fair comparison, either in hurd or osx, for comparing the merits and performance between that of monolithic and microkernel achitectures because so much extra stuff was added to a design never intended for posix. Something like QNX4 and later, designed both as a microkernel and for posix, or perhaps a pure mach system running applications designed specifically for mach, might be a more fare basis to compare the value of microkernel vs monolithic architectures.
Mach on hurd is easier to grasp and test since many of the lower level mach kernel services are still represented and usable there. Apple seems to be trying to eliminate visibility of as many of the lower level mach services from application developers as possible. Yet, there are still many things that can only be done in the mach kernel on osx or darwin (such as threads that can be cancelled on socket operations or sleeps). If one wanted a bsd/posix compliant environment, I think Apple would have been far better off starting from PPC/xBSD or Linux kernels, rather than trying to rope and rebuild mach to fit into something it was never originally designed for.
They're both better! (Score:5, Insightful)
What's better? PHP or Python? What's better Pepsi or Coke? The answer is always the same. It depends what your goals/needs/desires are. Neither is "better" in the all encompassing good or bad definition unless you qualify it. Which one's better for performance? Probably the monolithic kernel. Which one's better for security? Probably the micro-kernel. But even then, you have to qualify both of those. Performance of what? Security of what?
I'm sick of all these stupid "which is better?" religious wars that geeks are always so interested in having. What's better? C++ or Java? What's better? IE or Mozilla?
They're all better because the more there are, the more choices you have. There, is that a satisfactory answer?
MacOS / Darwin / xnu isn't a pure microkernel (Score:5, Insightful)
In general, monolithic kernels run in a single address space and use direct procedure calls / variable accesses to pass data and control flow between subsystems. This is true even if they support loadable modules (like Linux). Any driver or other subsystem in your kernel can (if it wants) access any other part of the kernel.
Although Mach itself is a microkernel, the "xnu" kernel which Darwin / MacOS X uses also hosts other components *in the same address space*. Some of the subsystems (e.g. the BSD subsystem) are large and resemble monolithic systems themselves. The overall system is not a "pure" microkernel, with lots of code moved out of privileged mode. Equally, it's not quite like a traditional monolithic UNIX because of the use of Mach and the other Darwin-specific components (e.g. a (relatively?) stable binary interface for drivers).
This article is troll. (Score:4, Funny)
Let's secretly watch (Score:5, Funny)
Now, let's see if he notices!
Re:Let's secretly watch (Score:4, Funny)
Parent
an old joke... (Score:5, Funny)
"Mach was the greatest intellectual fraud in the last ten years."
;login [usenix.org], 9/1990
"What about X?"
"I said `intellectual'."
OS X's kernel is not Mach. (Score:5, Informative)
Amit Singh has a well-written page about XNU: http://www.kernelthread.com/mac/osx/arch_xnu.html
NOT A MICROKERNEL (Score:5, Informative)
It uses Mach and BSD in THE SAME ADDRESS SPACE. As such, it's basically as monolithic as it gets. It just happens to incoporate Mach in the kernel space and uses it for threads and IPC.
Anyone who takes 10 minutes to look at the Darwin documentation would know this.
I wish
Apple does NOT use the MACH kernel. (Score:5, Informative)
It uses code FROM Mach, but it is not Mach and it is not a Microkernel. NT (NT 4.0, NT 5.0 (win2k), NT 5.1 (WinXP) does not use a Microkerenl either.
The only OS that I know of that actually uses a Microkernel is GNU/Hurd.
The OS X kernel, called XNU, is a mixture of *BSD kernel code and Mach kernel code.
Yes, yes, there was a ancient debate between Linus and that other guy about Micro- vs Macro-kernels, and guess what, Linus was right.
Apple does NOT use a microkernel. It does not use Mach. It is BASED on Mach. It would be considured a kludge compared to Linux or FreeBSD, but it works out fine.
Similar to how Mustangs are based on Ford Falcons and Granadas from the late 70's and early 80's. Those cars were as much as a failure as Mach, however the Mustang is flashy and many people desire it. So go figure.
The problem with Mach (Score:5, Interesting)
What's sad about this is that the failure of Mach tainted ALL ukernels. By the mid-1990s the idea was basically dead. But what an idea! Don't have your machine on a network? Simply don't run the network program. Using a diskless system? Don't run the disk server. Don't want _VM_... no problem. You can use the exact same OS image to build anything from a minimal OS for a handheld to a full-blown multi-machine cluster, without even compiling. No pluggable kernels, no shared libraries, no stackable file systems, nothing but top and ls.
But it just didn't work. IIRC performance of a Unix app on a truly collection-of-servers Mach was 56% slower than BSD. Unusable. Of course you can compile the entire thing into a single app, the "co-located servers" idea, but then all the advantages of Mach go away, every single one.
Now, given this, the question has to be asked: why anyone would still use it? Don't get me wrong, there are real advantages to Mach, notably for Apple who ship a number of multiprocessor machines. But the same support can be added to monokernals. Likewise Apple's version has support for soft realtime, which has also been added to monokernels. So in the end the Mac runs slower than it could, and I am hard pressed to find an upside.
Of course it didn't have to be this way. The problems in Mach led from the development process, not the concepts within. As L4 shows, it is possible to make a cross-platform IPC system that is not a serious drag on performance. And Sun's Spring went further than anyone, really re-writing the entire OS into something I find really interesting, and still providing fast Unix at the same time. I'd love to see someone build Mac OS X on Spring...
Re:The problem with Mach (Score:5, Interesting)
Sad, but true. The developers of Mach chose to start with BSD and tried to hack it into a microkernel, one section at a time. This was a flop. Mach 2.5, which Apple uses, is basically BSD with some Mach features. Mach 3 is more of a microkernel, but is so awful that nobody uses it.
There are really only two microkernels that work - VM, for IBM mainframes, and QNX. In both cases, incredible care was put into getting the key primitives - interprocess communication and scheduling - right. If those are botched, the system never recovers.
Mach suffered from too much "cool idea" syndrome. There's too much generality in key primitives that need to work fast. Message passing has too many options. The ability to build heterogeneous multiprocessor clusters out of whatever you have lying around complicates the simpler cases. And sharing memory across the network isn't worth the trouble.
It's clear from VM and QNX how a microkernel should work. Interprocess communication and scheduling need to play well together. Interprocess communication primitives should be like subroutine calls, not I/O operations. Try for an overhead of about 20%, and don't get carried away with the "zero copy" mania. Organize the I/O system so that the channel drivers that manage memory access are separate from the device drivers that manage the device functions.
This is how you get uptime measured in years.
Parent
Re:Monolithic (Score:5, Informative)
I can't believe people are modding you up for this.
The Linux kernel is monolithic. Linux modules do not run in user-mode. They are loaded into the kernel proper.
mkLinux was an Apple-sponsored effort to run Linux on Mach. The Linux kernel was modified to run in user-mode; it basically became an executable. In fact, you could run multiple instances of the same kernel (or different kernels) simultaneously.
Parent
Re:Monolithic (Score:5, Interesting)
mkLinux is not the only microkernel Linux - L4Linux is still maintained and is much more advanced. Nor are these the only Linux kernels to run in userspace - UML Linux, for example, does just fine. It is not clear where XEN fits into the picture.
All in all, though, the situation with Linux is actually a highly complex one, and should not be regarded as being definitely anything.
Parent
Re:Monolithic (Score:5, Informative)
I can. Maybe you're too young to remember when the term monolithic was commonly used to describe a kernel which, instead of using loadable modules, was linked as a single binary image. This was, and is, a valid use of the word. Here's an example [linuxjournal.com].
The first time I heard someone say that Solaris is monolithic, I thought that they were saying that, like SysVR3, it didn't support loadable modules. I didn't realize that, with the development of microkernels, the term "monolithic kernel" had started to be used in a different context.
Parent
Re:Monolithic (Score:5, Informative)
Parent
Re:Monolithic (Score:4, Informative)
basically all the interfaces are defined as symbols to the linker, and all interfaces are defined c-native.
the micro-kernels are meant to use message passing and more abstracted interfaces, as well as separate address spaces to ensure a bad module does not take down the entire kernel. Think of it like the modules run as only semi-privileged applications, handling their hardware and then giving control back to the micro-kernel which does as little as possible to arbitrate control and schedule between the subsystems and user-mode applications. Drivers are no longer fully privileged, and the entire user-space can be considered a subsystem of the kernel.
it's different, and kinda hard to design for, but i can't wait for hurd to release a linux compat layer.
Parent
Re:Monolithic (Score:4, Informative)
Parent
Re:Monolithic (Score:5, Informative)
No, you're mixing terms.
So, the linux kernel supports kernel modules, and its design is to some degree "modular" (as any project that size would have to be), but noone would claim it to be a microkernel.
--Bruce Fields
Parent
Re:Monolithic (Score:5, Informative)
a) running in kernel space, not user space
b) communicated with by predefined hooks, rather than a generic message passing interfacing.
That's why linux modules, which are superficially like elements of a microkernel, are not really like them at all.
Parent
Re:RMS, Is That You? (Score:5, Insightful)
RMS is very important, but he's a zealot, and a lot of people don't agree with his views (I for one don't on a lot of issues). Don't get caught up in the whole Saint iGNUcious thing.
Parent