PodSleuth Technical Overview
Basic HAL overview and terminology
The Hardware Abstraction Layer (HAL) is a system daemon that is accessible over DBus and exposes hardware devices in a tree called the Global Device List (GDL). Each device node in the tree exposes properties and sometimes methods from various interfaces. For instance, the storage interface exposes Eject, Mount, and Unmount methods. This document does not detail HAL other than what may be necessary to explain PodSleuth.
It is very important to note that HAL is basically passive. It does not do things like mounting volumes automatically. Mounting volumes is the job of a second application or daemon, such as gnome-volume-manager. gnome-volume-manager for instance runs in the background and listens to HAL for hardware added events. Only when HAL has finished probing the device and gathering properties does the device become exposed in the GDL. If a device is not in the GDL, external applications cannot see it. That is, gnome-volume-manager cannot mount a device until it is exposed by HAL in the GDL. Once exposed, gnome-volume-manager mounts the volume (taking hints such as the preferred mount point from HAL), and informs HAL that the volume is now mounted.
HAL supports "plugins," called "callouts." Callouts are commands that HAL will run when a given condition is met. For instance, PodSleuth's HAL layer provides conditions (by way of an FDI file, which is not covered in this document) that request HAL to run the PodSleuth HAL program when an iPod is plugged in. Callouts have access to the HAL device before it is added to the GDL and run as a child process of HAL itself, inheriting the HAL daemon's privileges (which are typically root).
PodSleuth's HAL layer
The core of PodSleuth is platform independent. All that is required for PodSleuth to gather the information it needs is access to the filesystem on the iPod (a mount point), and a method and permission to read from the SCSI code pages on the device.
However, on Linux, PodSleuth is most useful inside the HAL context. A layer around PodSleuth is available that integrates into HAL by way of a HAL callout. Because the callout runs as the same user as the HAL daemon (typically root), it is privileged to perform operations on the iPod that normally would not be allowed in a user context. This most specifically means access to the SCSI code pages, which is where Apple stores a crucial plist file that contains lots of metadata for the iPod.
As mentioned before, HAL does not mount volumes. It is the job of a mount daemon such as gnome-volume-manager to mount volumes and expose them in the user session. However, PodSleuth must read files on the iPod, which means it requires the iPod to be mounted. This is not a problem inside HAL for two reasons: the callout already has permissions to perform mounts using the low level mount system call (because it is running as root, for example), and because HAL has not yet exposed the device to the GDL, there is a guarantee that the volume is not already mounted.
PodSleuth temporarily mounts the volume, scans the file system for the data it needs, and then unmounts the volume before exiting. Once PodSleuth probes the iPod for all the data, it exposes its findings in the HAL device as properties. When the PodSleuth HAL callout exits, HAL may perform more probing, such as merging the storage interface into the device, and then exposes the device to the GDL. Once the iPod is exposed to the GDL, the mount daemon will take over, and mount the iPod. By the time the iPod is mounted and accessible in the user session, PodSleuth properties will be merged into the device, ready for an application to use.
