Loading Preferences and Settings

Many drivers may need some user–configurable per–device preferences or settings. For example, an audio device may have settings to control output volume level, which need to persist across system reboots. A driver cannot trivially access the file system (which is considered bad design anyway), so it cannot read the preferences from a file; however, An I/O Kit driver will have access to information stored in its plist file. The plist file is read-only and shared for all driver instances instantiated by a KEXT. Since a driver may create many instances, all which require different settings the plist file is unsuitable for this purpose.

Although you could implement your own scheme to put per–device settings in a plist file, it is not considered “good” design. Furthermore, it is difficult for an application to modify a plist file, as root privileges are usually required. Mac OS X does not offer a standardized mechanism or API for handling driver or KEXT preferences or settings. Therefore, if you need this capability, you must implement a user–space application to handle this for you. This can be done by installing a notification to wait for the device’s arrival and then call the driver’s user client using IOConnectCall*() functions to restore settings from a file. For information on how to install driver or device notifications, please refer to Chapter 5: “Interacting with Drivers from Applications.”

If you are implementing a driver for a non–removable device, you can have your user space settings helper run at boot or start time using a Launch Daemon or a Startup Item. You will have to register for a notification for your driver to ensure that the helper doesn’t run before your device has appeared. The process can exit once the device has appeared. If you have a removable–type device, such as a USB, FireWire, or Thunderbolt, you may instead wish to implement a persistent daemon (Launch Daemon) that listens for device arrival and restore settings once a device is plugged in. If the settings are specific to an application that uses the driver or device exclusively, you can manage the settings from the application itself and optionally restore the settings to a previous state once the application exits. The helper program or daemon may be able to run with the privileges of a normal user if the user client or kernel control it interacts with permits it.

If your driver handles multiple instances of the same device, it may be a challenge to figure out which settings belong to which device—either the ordering may not be consistent across reboots—or USB devices may be plugged in in a different order, or into different ports. To combat this, you can use a unique serial number or another identifier the device may have. A network interface should have a unique MAC address; a USB device usually has a serial number or something similar. Thunderbolt devices are guaranteed (in theory) to have a globally unique identifier (UID).