Apple’s largest session of the 1394 Developers Conference took place at Microsoft’s facilities in Redmond, WA. The two-hour session was well attended by both Mac FireWire developers and curious Windows FireWire developers. Eric Anderson, Manager of FireWire Software at Apple, lead a team of Apple FireWire engineers through a presentation of all aspects of FireWire on Mac OS X. In addition to being a manager at Apple, Dr. Anderson is a respected and active member of the 1394 Trade Association and has run a number of other well received general 1394 education sessions at the conference.
Anderson began the session by quickly showing off Mac OS X for the benefit of those who may not have seen it before. He ran through the standard demonstration of the dock, icons and other features of Mac OS X that should, by now, be well understood by MacCentral readers. He also described the layered design approach of Mac OS X, and briefly explained the OS’ NeXT, Mach and BSD underpinnings. Anderson also pointed out to developers that FireWire has shipped on Macs for years, and that 100 percent of Apple products will support FireWire.
Next, there was a demonstration of Target Disk Mode (TDM). TDM is a way for the hard disk of a Mac with a FireWire port to be used as a drive.
First, start up the Mac that you wish to be in TDM and hold down the ‘T’ key. This tells the Mac to boot up just enough to allow the drive to mount in TDM. A blue screen comes up (Anderson joked that a blue screen on a Mac is a good thing) which flashes the FireWire logo as a screen saver. Next, take a FireWire cable and connect the Mac in TDM to a running Mac. The Mac in TDM’s disk drives should appear on the desktop of the running Mac just like any other FireWire volume. You can use TDM to move files, troubleshoot an errant Mac or do anything else to that Mac’s disk that you could do to a FireWire volume. All of Apple’s products that ship with FireWire support TDM, not just the portables that were used for this demonstration.
After demonstrating TDM, Anderson briefly showed off iTunes, which works with FireWire CD burners, and iMovie, which takes advantage of FireWire DV cameras.
Finishing with iMovie, Anderson got down to the extremely technical nitty-gritty of how FireWire works in Mac OS X. He began by showing the layered software stack of Mac OS X describing where FireWire services are provided and how commands and data are moved up from the Mach kernel all the way through to the Carbon and Cocoa layers of Mac OS X.
At the base of Mac OS X is the Mach Kernel, and within the kernel are the drivers for all the hardware of the Mac. Included in these drivers are the FireWire drivers. The basic theory is that drivers control the physical hardware, and what the hardware does is controlled by higher-level services within Mac OS X. Some FireWire devices communicate through all the layers of the OS, and some can communicate directly with the top Carbon and Cocoa layers of Mac OS X.
For example, a FireWire disk drive goes through the whole OS. The FireWire drivers physically control the device, but the data must move through the I/O Kit, the BSD Kernel’s file system and so on up to your application. But, it is also possible for devices like a FireWire scanner to skip around the whole Mac OS X software stack. In this case, the drivers communicate directly with the applications plug-in.
Without going through the dozen or so layers of the FireWire stack loading procedure in Mac OS X, here is the general theory. When a device is plugged into a Mac running Mac OS X, the OS goes through a bottom-up iterative search process to gather up and activate all of the proper software to run that device.
The first thing that Mac OS X does when a device is plugged in is to determine what type of device it is. Many parts of Mac OS X’s I/O (Input/Output) services come from the PCI bridge, so the first thing the Mac must do is determine that it is a FireWire device instead of, say, a USB device. Higher layers of the kernel negotiate how the FireWire device will run, negotiate the necessary bus, protocol and speed issues, and load up the proper driver for the device. Finally, the device becomes available to the user or the application. While it seems complicated, Mac OS X does this in seconds.
All FireWire devices must have a suitable configuration ROM to identify itself to Mac OS X. “If your device has no config ROM,” said Anderson, “forget about using it with Mac OS X. There’s no way to find out what your device is.”
At each pass and at each level, Mac OS X becomes more specific in what kind of device is connected and how it will behave. This ensures that only the necessary software for the device is running when it needs to, and at the same time allows Mac OS X to have access to all of the necessary software for a wide variety of devices.
Many devices use standard FireWire drivers. Apple maintains drivers for common devices like scanners, DV cameras, mass storage devices and the like. For example, Apple’s standard Mass Storage FireWire driver can handle almost all ATA to FireWire bridges available today. This is the hard part of creating a FireWire hard disk, as all FireWire hard disks are ATA devices that use a FireWire bridge to translate the ATA signals into FireWire.
Developers also have the tools to create drivers with specific features. These features can be added in at various levels of the OS from the kernel all the way up to the application.
Apple has worked hard to ensure that performance remains optimal regardless of whether driver software resides in the kernel or at a higher level of Mac OS X. To facilitate developers writing software for their devices that does not reside in the kernel, Apple has created the FireWire Device Interface. Also called the User Client, this API (Application Programming Interface) allows application space drivers to work similarly to in-kernel drivers. Apple claims that there is little or no performance penalty for writing to the FireWire Device Interface, and that it is far easier to debug.
Currently, DV is handled within the kernel because Apple wanted to ensure that it was fast enough and that it could properly handle isochronous data transfers. (FireWire can be either isochronous — the data is transferred at a specific rate at specific times, essential for DV and audio to prevent skipping –or asynchronous — data which is not transferred on a specific timetable.) However, Anderson said that Apple would probably move DV to the application space via the user client — noting that acquiring DV data is essentially a plug-in.
After carefully walking through all of the layers within Mac OS X’s FireWire implementation, Apple engineer Collin Pieper walked through a series of how-to’s that outlined what needs to be done to create drivers for a variety of common devices. He covered printers, DV cameras, FireWire web cams, storage devices and scanners. Apple Engineer Niels Gabel also outlined strategies for developing FireWire drivers for new devices that do not fit into any of the above strategies. Gabel also demonstrated a FireWire development project in Project Builder — Apple’s IDE (Integrated Development Environment) in Mac OS X.
Apple also showed off some of the tools from its Mac OS 9 and X FireWire SDKs (Software Development Kits). For Mac OS X, there was IORegistryExplorer. This application looks at exactly what I/O software and devices are active within the system and provides detailed information about them. This can be done dynamically, and it was demonstrated by showing the events that occurred when a FireWire device was plugged in.
For Mac OS 9, Jeremy Nelson, FireWire Senior Test Engineer at Apple, demonstrated FireBug. This free application observes and records all of the activity on the FireWire bus. This can be an incredible amount of data, but FireBug can sort this data and show a developer specific events on the FireWire bus. The developer can then use this information to fix his or her product. FireBug is free, and is a part of Apple’s FireWire SDK. However, FireBug only works with Texas Instruments’ PCILynx FireWire chipset. Unfortunately, this chipset is becoming difficult to find. Newer’s FireWire2Go PCMCIA FireWire cards used this chipset. Since Newer has closed, these are in demand. Also, TI still has some FireWire PCI cards that still use the chipset.
Nelson also outlined Apple’s testing strategy for ensuring the quality of FireWire products across all of Apple’s systems, past, present and future. Apple maintains a large bug-tracking database which developers can gain access to. Apple’s testing is extensive, ranging from performance evaluation to detailed analysis of a device’s bus activity and behavior with other devices. Nelson encouraged all developers to send their products to Apple for evaluation to ensure the devices’ future compatibility with Mac systems.