“Mac OS X Internals” Review

This is a critical review, chapter by chapter, of Amit Singh's “Mac OS X Internals”, henceforth known as MOXI. The reviews and comments of subsequent chapters will appear as I complete reading them.

Chapter 1

Jul 22 2006

Some of the information in this introductory chapter about the origins of Mac OS X, including all the code-names about Apple operating systems prior to OS X, could have been eliminated entirely or put in an appendix; it contributes nothing to OS X internals. MOXI should have started with the chapter on RIG (the true beginnings of OS X's Mach heritage) and proceeded chronologically to the creation of NeXT.

This chapter is missing a section with details about Darwin. When I first came upon the word on p. 34 (there is also a figure that mentions Darwin and OpenDarwin), I wondered if I and accidently skipped a section and I even flipped-back several pages to verify that I hadn't. Darwin is not elaborated upon until Chapter 2.

I did very much enjoy the tidbits of trivia strewn throughout the chapter, showing that The Book was well researched.

Comment: What about information on DNS?

Someone on #macosx asked about why a host wasn't resolving and I suggested looking at /etc/nsswitch.conf, typically, the file that the name server looks for the order in which to do lookups. Well, it so happens that OS X doen't have that file. So I turned to MOXI as it was lying within easy reach. I looked up DNS in the index— nope, nothing.; the closest match was "Domain Initialization". So then I tried looking under "N" for Name Service— ah! pages 1060-1079 — unfortunately there's a big diagram and some stuff related to IPC and bootstrap servers. Hmph! Dissappointing.

David responds:

Looking at the table of contents of the book's site, it seems that the scope of the book is different than what you're expecting. MOXI is about the underlying architecture of the OS, like McKusick's "The Design and Implementation of..." books.

Things like DNS are more application- and user-level things built on top of the architecture that the books describes. Most administrators don't need (or want) to know how the memory pager works, or how the HFS+ file system is described.

If Amit Singh wrote a book about administering OS X, I would buy it.

Chapter 2

Aug 2 2006

One of the nice things I like about OS X is the ability to authenticate on-the-fly whenever escalated privileges are required to perform some section. The section on Security in Chapter 2, shows how to query the Authorization Services using a small demonstration program that communicates with the securityd Security Server.

I was also quite impressed with the variety of debugging tools (p. 129) available to OS X developers.

If this isn't a book about System Administration, why is there a section on System Administration (2.4.13, p.139) that briefly mentions Netinfo, Auditing, Managing System Configuration, OS X Server Xgrid, Xsan? This whole section could have been edited out or better named. (So you see why I was confused about not finding a single mention about DNS.)

Chapter 3, Inside an Apple, looks juicy.

A Comment on The Figures

There is something that bothers me about some of the figures in this book. I don't quite know what it is but they look like they don't quite belong with the rest of the book layout. I don't know how else to put it. I don't know if it's the sans serif font, the differently shaped boxes or the different shades of grey. I had the same feeling with the figures in the O'Reilly series of books. The Xsan Figure looks fine, but the others are disconcerting.

Chapter 3

Aug 12 2006

I skimmed most of this chapter as it deals with the architecture of the PowerPC 950FX microprocessor which is now a mere historical curiosity in the grand scheme of Apple's game-plan.

Most of this chapter adds nothing to the understanding of the internals of OS X. The annotated assembly-language listing of a program that calculates factorials is interesting as trivia.

Chapter 4

Aug 12 2006

Is a computer that uses sophisticated firmware, rather than a bare-bones BIOS, over-engineered or is it beautifully engineered? If there is an aspect of the computer's operation that the user will never see or will never know the existence of, does the designer have to put much effort into it? If it is an Apple or a Sun, the answer to the first question is that it is beautifully engineered and the answer to the second question is "yes". Asking "why", is pointless because it would be like trying to explain the concept of elegance to a monkey.

I have never dropped down to the firmware of my Mac (and I hope I never will— I bought my Mac so I wouldn't have to admin a Unix computer at home). My experience with Open Firmware is limited to Sun workstations: booting them, re-installing them over the network via JumpStart, setting the firmware password and re-setting firmware to factory defaults.

Chapter 4 begins with a primer on the Forth programming language and demonstrates that Open Firmware, written in Forth, is sophisticated enough to allow a graphical Towers of Hanoi program, with multi-coloured disks, to be written and run on the Mac. It continues with an explaination of the bootloader, BootX and concludes with a brief description of EFI, the Extensible Firmware Interface, which replaces the 20 year old PC BIOS.

Chapter 5

Aug 20 2006

I skimmed through most of the first half of this chapter, which contains a catalog of the function calls the kernel makes as it initializes after the bootloader, BootX, loads it.

One notable section, amongst the catalog of function calls, is the description of how the kernel-panic image can be substituted with a custom image. I should note that OS X was the first OS I used that had a graphical kernel-panic handler. All the other operating systems have text based screens— Linux and FreeBSD just "puke" massive quantities of text onto the console screen; Solaris just draws the console messages onto the graphical screen in text mode and Windows dies a Blue Death.

The section on user-level startup, beginning with launchd, the first user-level process that runs, explains how an XML file is used to configure its operation. There is a good example of how to create a user-level daemon (referred to as "agents") that runs a cron job. It would be interesting to do a comparison between launchd and Solaris 10's Service Management Facility (SMF). SMF can show the depencies amongst the various services and can place services in maintenance mode if they are malfunctioning.

Chapter 6

Sep 29 2006

Chapter 6 begins with a tour of the kernel source tree and then describes how tasks and threads execute on the kernel. In OS X, what is traditionally referred to as a process in the Unix world, is further sub-divided into a task and one or more threads; the task portion is a data structure that the kernel uses for "book-keeping" various aspects of the process and it is the thread(s) that actually executes.

The section on Mach is the most confusing I have read so far requiring me to re-read particular sentences several times, to try to understand the meaning; for example (p. 512), "Note that a task's resources include Unix items too, which on Mac OS X are contained in a task thorough its one-to-one association with a BSD process structure." I still don't know what this means.

Release 3 of Mach was designed so the OS, BSD, ran in user space. I get the vague impression that in OS X, BSD runs in kernel spae. But I did not find this explicitly stated and seems only to be hinted at in the "Kernel Task" sidenote; "Thus xnu is a monolithic kernel containing markedly different components such has Mach, BSD and the I/O Kit, all running as groups of threads in a single task in the same address space." This section is in need of a rewrite and a few block-diagrams to clarify a few points.

There follows a section of programming APIs (with several programming examples and on exception handling and processing in great detail. Please don't look at the digram on page 555 because you will just become more confused than you already were (at least I was).

sy_arg_munge32 and sy_arg_munge64 are a pair of most interestingly named functions in the sysent structure in bsd/sys/sysent.h that adjust 32-bit arguments from user space to 64-bit in kernel space.

Then a section on trap-handling and ultra-fast traps (traps that don't require previous state to be restored) and Bluebox (OS9 support) in the kernel.

The chapter on kernel debugging begins with remote kernel debugging support— gdb running on a remote host can be connected via Firewire or wired ethernet but not wifi because the Airport driver doesn't support KDP (kernel debugging protocol). It is full of details that I found dry and uninteresting until I got to the part about generating memory dumps where the text console's frame buffer is dumped to a file as raw pixel-data and then converted to a jpeg using a perl script and the pbm utilities. That's the kind of stuff I like to read about. The scary diagram on page 621 describing the auditing system looks like it was just converted from a scribble on a piece of paper to line-art with no thought given to layout.

Then, it's on to VMM, the Virtual Machine Monitor, a facility that VirtualPC used to emulate PC hardware.

Section 6.10 is for those who love tweaking the kernel to optimize it for their particular preferences and then compile their own version. The kernel is typically compiled with a specific version of the GNU compiler (gcc_os) which is a few versions behind the latest and greatest. Hence, those that wish to compile their own kernel will end up installing two versions of gcc— one to compile the kernel and the other to compile all the other apps.

luis fernandes / elf@ee.ryerson.ca / G4 Powerbook Journal