Forgot your password?
typodupeerror
Operating Systems Software Businesses Apple

Get To Know Mach, the Kernel of Mac OS X 413

Posted by Hemos
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.

Get To Know Mach, the Kernel of Mac OS X

Comments Filter:
  • by Anonymous Coward on Monday May 16, 2005 @10:39AM (#12543304)
    The apple metrosexuals vs the greasy bearded GNU/linux hippies! Who will win!
    • Who will Win?!?!

      Tune in next week to the same article (poasted at a later dupe-date for your conveinance) and FIND OUT!

      We're also to believe that the Apple Metrosexuals plan to use a hypnotizing-GayRay against the dirty hippies!

      SAME TIME SAME CHANNEL!
    • by ikewillis (586793) on Monday May 16, 2005 @01:00PM (#12544699) Homepage
      XNU, the kernel of OS X, is a hybrid of Mach and select BSD code, which leans substantially more towards a monolithic kernel design. What Mach typically handled in a microkernel manner with servers, namely things like the VFS, networking, etc. have all been completely removed in XNU. Where once there were Mach servers there is now the FreeBSD Unified Buffer Cache, to which Apple has attached various FreeBSD subsystems like the FreeBSD VFS and network stack.

      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.

  • by hector_uk (882132) on Monday May 16, 2005 @10:41AM (#12543331)
    commence the dead horse beating. i start : mach owns.
  • by Anonymous Coward
    So people can do the

    You got a light Mac?
    No, but I've got dark brown NeXT machine.

    joke.
  • MirrorDot (Score:4, Informative)

    by cirisme (781889) on Monday May 16, 2005 @10:42AM (#12543348) Homepage
    Huge PDF on Slashdot. This can't end well. Mirror [mirrordot.org]
  • by DoctoRoR (865873) * on Monday May 16, 2005 @10:44AM (#12543368) Homepage
    This appendix on Mach is from the newest edition of the classic "Operating System Concepts," Seventh Edition by Silberschatz, Galvin, and Gagne (Wiley). ISBN: 0-471-69466-5. Published December 2004.

    There are also free online chapters for FreeBSD and Nachos.

    Link to Wiley's purchase page (given that we are /. them): http://www.wiley.com/WileyCDA/WileyTitle/productCd -0471694665.html [wiley.com]
    • by LanMan04 (790429) on Monday May 16, 2005 @10:50AM (#12543440)
      *Commence horrible flashback to "OS Design" class as an undergrad*...

      • WHY? WHY DID YOU HAVE TO REMIND ME?

        The therapy was working.. I had almost blotted out the existence of Nachos altogether. Now it's all coming back. Why do you feel the need to hurt me so? *sob*

        -Laxitive
    • Interestingly the chapter was pulled in the 5th edition.. but the chapter was offered online at the time of publishing (it was in my OS class file).

      acording to the preface from 5th "coverage of the Mach operating system (old chapter 20), which is a modern os.... is available on line."

      Back into relevance? The new article doesn't mention MAC OSX which doesn't mean it completely out of date.

      It should be noted that appe hired Avie Tevanian to modify the MACH kernal and boost its performace.

      http://everythi [everything2.com]
    • What's interesting is the utter irrelevance of the slashdot posting to the book excerpt. Slashdot talks as if it's a detailed article on the internals of Darwin, which is the OSX kernel, NOT MACH. Darwin is based on Mach, yes, but it's not Mach. And the article never once mentions OSX, or Apple, or Macs. One must seriously wonder...is the ability to read included in the job requirements for a slashdot editor?
  • by iggymanz (596061) on Monday May 16, 2005 @10:44AM (#12543372)
    The modular design of microkernels makes for easier design & debugging, and with some designs the freedom to make user space services that can only be in privileged space in monolithic designs, but does one want to pay the overhead for all that message passing? Now that we are getting into parallel processing at the consumer level with multicore and hyperthreaded chips, maybe the answer is yes.
    • The modular design of microkernels makes for easier design & debugging, and with some designs the freedom to make user space services that can only be in privileged space in monolithic designs, but does one want to pay the overhead for all that message passing?

      No, which is why Apple's XNU runs in one address space for the most part (I don't even know whether there are parts which don't), and most message passing has been reduced to plain function calls. They still have the design advantages of s

    • L4 performance? (Score:3, Interesting)

      by emil (695)

      HURD abandoned Mach because of performance issues and is being reimplemented on L4 [l4ka.org].

      If Apple had chosen L4, would it have been necessary from a performance perspective to include BSD at a peer level with the microkernel?

      Is it now far too late for Apple to dump Mach?

  • by licamell (778753) * on Monday May 16, 2005 @10:45AM (#12543382)
    Warning: link is to a PDF"

    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.
  • As always... (Score:5, Insightful)

    by jtpalinmajere (627101) on Monday May 16, 2005 @10:45AM (#12543383)
    ... benefits and detriments exist for both monolithic and micro flavors. I doubt a conclusion could ever be made about which one is 'better'... because it all depends on context. "How will the system be used?" "What kind of environment will the system be operating under?" "What are the performance goals of the system?" "What types of hardware will the system(s) need to support?"

    Each system has benefits... but they almost always rely on the existence of certain assumptions.
    • Re:As always... (Score:3, Interesting)

      by jd (1658)
      That is very true. Arguably, though, what you have is a continuum, with monolithic kernels at one extreme and exokernels (virtually everything in userspace) at the other extreme. Different requirements would need different designs, somewhere on that continuum, but there would be no "overall best" for all circumstances.

      Actually, as kernels have started adding parallelism (such as SMP, clustering, etc), it becomes harder to really say exactly what sort of design a kernel really has. (Design is intrinsic and

  • by Kipsaysso (828105) on Monday May 16, 2005 @10:46AM (#12543392) Homepage Journal
    Let's ask what OS is better. The Apple and Linux people will go at each others throats and will in the end agree that they hate Window$.

    Smucks.
  • mach inject (Score:5, Informative)

    by Kaamoss (872616) on Monday May 16, 2005 @10:46AM (#12543397) Homepage
    I thought the article was more than relativly informative. Personally I love my mac and I think it's about time people stop fighting over which OS is better, use the right tool for the job, be that Linux, mac, windows, whatever. Anyways, figured I'd throw in a link to some other cool stuff about mach. http://rentzsch.com/papers/overridingMacOSX [rentzsch.com] The page deals with code injection and function overriding within MAC OS X. I think something like it was on here not too long ago but it's also pretty interesting stuff, I'd suggest the read.
    • use the right tool for the job, be that Linux, mac, windows, whatever

      Yes. For instance, if you're wanting to test out the effects of the latest greatest spyware, use Windows and IE to do anything on the Internet.
    • Re:mach inject (Score:3, Insightful)

      by TheNetAvenger (624455)
      I just had to comment, your post is very refreshing and what I remember the OLD days of Slashdot being like.

      It really isn't so hard to say, all OSes have really cool things about them, and we should talk about these cool things, as they enrich the OSes we develop for or use.

      Why can't something Microsoft does actually be cool, or something Apple does actually be outstanding, or a *nix project create a whole new paradigm that is fantastic.

      Anyway, thanks for the feeling of the old days when people didn't bi
  • by dumbnose (190140) on Monday May 16, 2005 @10:46AM (#12543402)
    Mac OS X uses Mach, but it also uses a FreeBSD kernel and compiles them together. This eliminates the runtime characteristics of a Microkernel. This is actually quite common.

    So, even though it uses Mach, you can't call it a Microkernel.

  • by TheViffer (128272) on Monday May 16, 2005 @10:48AM (#12543420)
    Linux is a kernel, not an operating system.

    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".
  • Xnu, not mach (Score:5, Informative)

    by oudzeeman (684485) on Monday May 16, 2005 @10:50AM (#12543445)
    Apple's kernel is called XNU (Xun's not Unix). It is based on Mach with a BSD compatibility layer included at the kernel level (as are various other subsytems usually implemented at a server level in true microkernels), not as a 'mach server'. It does not use Mach as a microkernel. Xnu is a essentially a monolithic kernel. The Mach code takes care of inter-process communication, virtual memory, preemptive multi-tasking, etc. The BSD codebase of XNU handles user ids, file permissions, TCP/IP stack, sockets, filesystems

    stop spreading the myth that Xnu is a microkernel

  • by kriegsman (55737) on Monday May 16, 2005 @10:51AM (#12543454) Homepage
    Operating System Concepts is a great book for learning about what an OS is and the design choices that go into building one. We used that book way back in my college days, and it's one of the few textbooks I actually kept. Here's an excerpt from the (linked PDF) chapter on Mach:
    Mach 2.5 is also the basis for the operating system on the NeXT workstation, the brainchild of Steve Jobs, of Apple Computer fame.

    So... does anyone here know what Steve Jobs and Mach have been up to since their halcyon days at NeXT?
  • Firefox has an extension for PDF Downloading which gives you the option to download a pdf link, in case opening pdfs in browsers bothers anyone.

    PDF Download [mozilla.org]
  • by Toby The Economist (811138) on Monday May 16, 2005 @10:53AM (#12543482)
    "The debate around Monolithic (Linux) and Micro (Mach) kernels continues..."

    There is no debate. It has been well accepted that micro-kernels are the way to go.

    --
    Toby
  • Mac != Mach (Score:4, Interesting)

    by frankie (91710) on Monday May 16, 2005 @10:55AM (#12543500) Journal
    Although Darwin does use Mach at the heart, it also has large chunks of the BSD kernel bolted on to avoid Mach's typical performance hit. Consequently, OS X really isn't microkernel, and you can't do all the cool microkernel tricks (load or unload almost anything dynamically, drivers can't crash the OS, etc).

    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)

    by dyfet (154716) on Monday May 16, 2005 @10:56AM (#12543512) Homepage
    Mach was never originally engineering for posix compliance, and yet the two main operating systems built from it, osx (and darwin), and hurd, each have tried hard to tame and make mach behave posix compliant. This has sometimes produced interesting compatibility issues, especially in the contenous issue of posix threading, and has resulted in compatability layers which weigh down the system further.

    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.

    • Re:mach vs posix (Score:3, Informative)

      by Dink Paisy (823325)
      Technically, that may be correct (Mach developed without aim for POSIX compliance), but considering the title of the original Mach paper was, "Mach: A New Kernel Foundation for UNIX Devlopment," it's a silly statement. Mach was made explicitly for implementing UNIX-like operating systems.

      The level of Mach-iness of OS X is another good question, though. From what I gather, OS X looks more like a monolithic BSD kernel ported to a Mach/PPC architecture (where instead of targeting the PPC architecture, OS X's

  • by Pedrito (94783) on Monday May 16, 2005 @10:56AM (#12543520) Homepage
    "Which design is better?"

    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?
  • by Lemming Mark (849014) on Monday May 16, 2005 @11:00AM (#12543553) Homepage
    That's a statement not a criticism by the way ;-)

    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).
  • by Anonymous Coward on Monday May 16, 2005 @11:01AM (#12543566)
    Period.
  • by Anonymous Coward on Monday May 16, 2005 @11:08AM (#12543627)
    as we switch Steve Job's kernel beans with new Roaster's Light Linux Beans.

    Now, let's see if he notices!
  • by Lemming Mark (849014) on Monday May 16, 2005 @11:21AM (#12543737) Homepage
    Monolithic kernels are dominant in practice (so far). Windows started off microkernel-y but has ended up rather monolithic (at least partly for performance reasons). Xnu (Darwin / MacOS kernel) also has strong monolithic leanings, despite being based on Mach.

    The microkernel design still appeals, though. For some things (not all) it is beneficial to move stuff out into less-privileged units. (Small) examples of this in Linux include: FUSE (for implementing non-performance-critical filesystems in Linux userspace), udev instead of devfs, moving initialisation code to the initramfs instead of being in the kernel itself...

    Other systems (e.g. Dragonfly BSD) are also seeking to move functionality to userspace where possible without undue complexity and / or performance cost.

    Some argue that virtual machine monitors are a useful modern equivalent to microkernels. They perform a similar function (partitioning system software into multiple less privileged entities), although they do it in a more "pragmatic", less architecturally "pure" way.

    Virtual machine monitors allow multiple virtual machines to use the same hardware. They have also been used for running Linux drivers in fault-resistant sandboxed virtual machines, with performance within a few percent of a traditional monolithic design (fully privileged drivers).

    The L4 microkernel is being used as a virtual machine monitor for this work by one research group, Xen has these capabilities also.
  • Mach Sucks (Score:4, Informative)

    by Unknown Lamer (78415) <`clinton' `at' `unknownlamer.org'> on Monday May 16, 2005 @11:21AM (#12543740) Homepage Journal

    Mach is painfully slow. It's an old microkernel and it uses async IPC (to allow for passing messages over the network). This is slow because you have to do a ton of context switches and copy the message between address spaces.

    L4 [l4ka.org], on the other hand, uses sync IPC. It has a bunch of neat optimizations, but the main reason why it's faster than Mach is that it doesn't have to copy messages. You send an IPC and it goes into the part of your VM space that L4 sets aside for IPC and then L4 does a quick context switch to the target task, it processes the IPC, and then you get your data back. (Simplifyed a ton).

    So, microkernels rock. Mach sucks.

  • by rplacd (123904) on Monday May 16, 2005 @11:21AM (#12543752) Homepage

    "Mach was the greatest intellectual fraud in the last ten years."
    "What about X?"
    "I said `intellectual'."
    ;login [usenix.org], 9/1990

  • OS X's kernel, "xnu", is /based/ on Mach 3.0 and obviously shares a few concepts with Mach, but is neither a pure Microkernel, nor are all its components from Mach.

    Amit Singh has a well-written page about XNU: http://www.kernelthread.com/mac/osx/arch_xnu.html
  • NOT A MICROKERNEL (Score:5, Informative)

    by Leimy (6717) on Monday May 16, 2005 @11:23AM (#12543775)
    Mac OS X does not use Mach like a microkernel at all. I wish people'd get this through their thick skulls.

    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 /. would actually edit for content.
  • by Anonymous Coward on Monday May 16, 2005 @11:25AM (#12543798)
    The kernel that Apple uses in OS X is called XNU.

    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.
  • by gosand (234100) on Monday May 16, 2005 @11:31AM (#12543858)
    Here is your answer: For the most part, Mac people don't even know what the heck a kernel is. Linux people are nearly required to.
  • by Maury Markowitz (452832) on Monday May 16, 2005 @11:31AM (#12543859) Homepage
    Although interesting, Mach was developed at a university and shows a huge number of problems as a result. Notably performance is terrible, due largely to the IPC performance. When people actually tried the "collection of servers" operating system in Mach 3, it was clear it was simply not a workable solution. Workplace OS, Star Trek and any number of other OS's died as a result.

    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...
    • by Animats (122034) on Monday May 16, 2005 @12:42PM (#12544530) Homepage
      Although interesting, Mach was developed at a university and shows a huge number of problems as a result.

      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.

  • Exokernels (Score:3, Interesting)

    by Jotham (89116) on Monday May 16, 2005 @11:39AM (#12543939)
    Mono vs Macro... what about Exo [mit.edu]
  • by Anonymous Coward on Monday May 16, 2005 @11:47AM (#12544015)
    Just because it runs on Mach doesn't mean that MacOS X is a microkernel architecture.

    Just as an example, on the new MacMini hardware, sound level control is done in kernelspace (since HW doesn't support that anymore)! Whereas the LinuxPPC developers refuse to do things like this in kernelspace.

    Actually in Linux many things are pushed out to userspace (think udev), making it much more microkernel-like than MacOSX.

    (Not that Apple-Fanboys would understand anything of that)
  • Mono / Micro (Score:4, Insightful)

    by spring (116537) <eric&bitpuddle,com> on Monday May 16, 2005 @11:57AM (#12544112) Homepage
    Linux is in spirit a monolithic design, and MacOS is in spirit a mach-based microkernel design.

    In reality, though, both MacOS X and Linux have departed from the architectures in mostly pragmatic ways. OS X is not a "pure" microkernel in the mach sense.
    • Linux is in spirit a monolithic design, and MacOS is in spirit a mach-based microkernel design.

      More like Linux is like a farming co-op, XNU is Monsanto.

      Or, maybe Linux is like a monkey with a spanner, and XNU is like a komodo dragon with a toothache.

      No, wait. Linux is like a pulmonary thrombosis! and XNU is the dropped sponge in a gastric bypass!

      Damn! OK! I admit it! My analogies have fallen, and they can't get up.

      I will now explain the difference with an interpretive dance, perhaps some origami.

The only difference between a car salesman and a computer salesman is that the car salesman knows he's lying.

Working...