This situation can be confusing because symbolic links can be created for devices that are not yet generated. The symbolic links will be defined and held until needed, when the device is generated. This is why you usually have many more SYMLINK rules than NAME rules, though the NAME rules actually set up device files. In the case of removable devices, devices will not have a device name generated until they are connected.
In the 50-rules.udev file you will find numerous SYMLINK rules for optical devices like the one shown here for SCSI CD-ROMs:
KERNEL="scd[0-9]*", SYMLINK="cdrom%e"
In most cases, you'll only need symbolic links for devices, using the official symbolic names. Most of these are already defined for you. Should you need to create a symbolic link, you can create a SYMLINK rule for it. However, a new SYMLINK rule needs to be placed before the name rules that name that device. The SYMLINK rules for a device are read by udev and kept until a device is named. Then those symbolic names can be used for that device. You can have as many symbolic links for the same device as you want, meaning that you could have several SYMLINK rules for the same device. When the NAME rule for the device is encountered, the previous SYMLINK keys are simply appended.
Most standard symbolic names are already defined in the 50-udev.rules file, such as audio for the audio device. In the following example, the device is referenced by its KERNEL key and the symbolic link is applied with SYMLINK key. This is only a SYMLINK rule. There is no NAME key to name the device:
KERNEL="audio0", SYMLINK="audio"
Hardware Abstraction Layer: HAL
The purpose of the Hardware Abstraction Layer (HAL) is to abstract the process of applications accessing devices. Applications should not have to know anything about a device, even its symbolic name. It should just have to request a device of a certain type, and then a service, like HAL, should provide what is available. Device implementation becomes hidden from applications. HAL is a software project of freedesktop.org, which specializes in open source desktop tools.
HAL makes devices easily available to desktops and applications using a D-BUS, device bus, structure. Device are managed as objects that applications can easily access. The D-BUS service is provided by the HAL daemon, haldaemon. Interaction with the device object is provided by the org.freedesktop.HAL service, which is managed by the /org/freedesktop/HAL/Manager.
HAL is an information service for devices. The HAL daemon maintains a dynamic database of connected hardware devices. In certain cases, this information can be used by specialized callout programs to maintain certain device configuration files. This is the case with removable file systems like CD-ROMs and USB card readers. HAL will invoke the fstab-sync callout program that will use HAL information to dynamically change managed entries in the fstab file. Removable devices are managed by fstab-sync with HAL information, telling fstab-sync when such disks are attached. The situation can be confusing. Callout programs perform the actual tasks, but HAL provides the device information. For example, though fstab-sync changes the fstab file, the options and mountpoints used for CD-ROM entries are specified in HAL device information files that set policies for storage management.
Device Information Files: fdi
Hal properties for devices are handled by device information files (fdi) in the /usr/share/hal/fdi and /etc/hal/fdi directories. The /usr/share/hal/fdi directory is used for configurations provided by the distribution, in this case, Fedora Core 4, whereas /etc/hal/fdi is used for setting user administrative configurations. In both are listed subdirectories for the different kinds of information that HAL manages, such as policy, whose subdirectories have files with policies for how to manage devices. The files, known as device information files, have rules for obtaining information about devices, as well as detecting and assigning options for removable devices. The device information files have the extension .fdi, as in storage-policy.fdi. For example, the policy directory has two subdirectories: 10osvendor and 30thirdpary. The 10osvendor holds the fdi files that have policy rules for managing removable devices on Fedora Core 4 (10osvendor replaced 90defaultpolicy, which was used in Fedora Core 3). This directory holds the 10-storage-policy.fdi policy file used for storage devices. Here you'll find the properties that specify options for removable storage devices such as CD-ROMs. The directories begin with numbers; lower numbers are read first. Unlike with udev, the last property read will override any previous property settings, so priority is given to higher-numbered directories and the fdi files they hold. This is why the default policies are in 10osvendor, whereas the user policies, which would override the defaults, would be in a higher-numbered directory like 30user, as are third-party policies, 20thirdpolicy.
There are currently three device information file directories set up in the device information file directories, each for different kinds of information: information, policy, and preprobe.
- Information: Holds information about devices.
- Policy: Sets policies such as storage policies. The default policies for a storage device are in a 10-storage-policy.fdi file in the policy/10osvendor directory.
- Preprobe: Handles difficult devices such as unusual drives or drive configurations, for instance, those in preprobe/10osvendor/10-ide-drives.fdi. This contains information needed even before the device is probed.
Within these subdirectories are still other subdirectories indicating where the device information files come from, such as vendor, thirdparty, or user, and their priority. Certain critical files are listed here:
- information/10freedesktop: Information provided by freedesktop.org
- policy/10osvendor: Default policies (set by system administrator and OS distribution)
- preprobe/10osvendor: Preprobe policies for difficult devices
Conclusion
Both udev and HAL usher in a radical new age of device management for Linux systems, Fedora Core in particular. As more devices become hotplugged, temporarily attached like a camera or moving from one system to another like small printers, it's crucial that device management become accommodating, automating device detection and configuration. It used to be that devices were few and rare, with only a couple used for any given system. These days numerous devices of all kinds are expected to connect and interact with your system. The old method of manually setting up a device interface is no longer practical. We are in an era where all devices are logically hotplugged, and fixed devices are just hotplugged ones that were never removed.
References
Subscribe to Linux Email News Alerts
Subscribe via RSS
