HAL 0.5.8_git20061106 Specification

David Zeuthen


            
          


Table of Contents
1. Introduction
1.1. About
1.2. Acknowledgements
1.3. Architecture of HAL
1.4. HAL on Linux 2.6
1.5. Device Objects
1.6. Device Capabilities
1.7. Using devices
2. Device Properties
2.1. Metadata Properties
2.1.1. info namespace
2.1.2. linux namespace
2.2. Physical Properties
2.2.1. pci namespace
2.2.2. serial namespace
2.2.3. usb_device namespace
2.2.4. usb namespace
2.2.5. platform namespace
2.2.6. ide_host namespace
2.2.7. ide namespace
2.2.8. scsi_host namespace
2.2.9. scsi namespace
2.2.10. ieee1394_host namespace
2.2.11. ieee1394_node namespace
2.2.12. ieee1394 namespace
2.2.13. mmc_host namespace
2.2.14. mmc namespace
2.2.15. ccw namespace
2.2.16. ccwgroup namespace
2.2.17. iucv namespace
2.2.18. block namespace
2.2.19. xen namespace
2.3. Functional Properties
2.3.1. volume namespace
2.3.2. system namespace
2.3.3. volume.disc namespace
2.3.4. storage namespace
2.3.5. storage.cdrom namespace
2.3.6. net namespace
2.3.7. net.80203 namespace
2.3.8. net.80211 namespace
2.3.9. net.irda namespace
2.3.10. net.80211control namespace
2.3.11. input namespace
2.3.12. pcmcia_socket namespace
2.3.13. printer namespace
2.3.14. portable_audio_player namespace
2.3.15. alsa namespace
2.3.16. oss namespace
2.3.17. camera namespace
2.3.18. laptop_panel namespace
2.3.19. video_adapter_pm namespace
2.3.20. ac_adaptor namespace
2.3.21. battery namespace
2.3.22. button namespace
2.3.23. processor namespace
2.3.24. display_device namespace
2.3.25. sensor namespace
2.3.26. power_management namespace
2.3.27. tape namespace
2.4. Policy Properties
2.4.1. storage.policy.default namespace
2.4.2. storage.policy namespace
2.4.3. volume.policy namespace
3. Device Information Files
3.1. Facts about devices
3.1.1. Example: MP3 player
3.1.2. Example: Digital Still Camera
3.1.3. Example: Card Reader
3.2. Policy settings for devices
3.2.1. Storage Devices
4. Examples and other stuff
4.1. Callouts
4.2. D-BUS Network API
4.2.1. Interface org.freedesktop.Hal.Manager
4.2.2. Interface org.freedesktop.Hal.Device
4.2.3. Interface org.freedesktop.Hal.Device.Volume
4.2.4. Interface org.freedesktop.Hal.Device.Storage
4.3. Enforcing Policy
4.3.1. Storage Devices

Chapter 1. Introduction

1.1. About

This document concerns the specification of HAL which is a piece of software that provides a view of the various hardware attached to a system. In addition to this, HAL keeps detailed metadata for each piece of hardware and provide hooks such that system- and desktop-level software can react to changes in the hardware configuration in order to maintain system policy.

HAL represents a piece of hardware as a device object. A device object is identified by a unique identifer and carries a set of key/value paris referred to as device properties. Some properties are derived from the actual hardware, some are merged from device information files and some are related to the actual device configuration. This document specifies the set of device properties and gives them well-defined meaning. This enable system and desktop level components to distinguish between the different device objects and discover and configure devices based on these properties.

HAL provides an easy-to-use API through D-BUS which is an IPC framework that, among other things, provides a system-wide message-bus that allows applications to talk to one another. Specifically, D-BUS provides asynchronous notification such that HAL can notify other peers on the message-bus when devices are added and removed as well as when properties on a device are changing.

The most important goal of HAL is to provide plug-and-play facilities for UNIX-like desktops with focus on providing a rich and extensible description of device characteristics and features. HAL has no other major dependencies apart from D-BUS which, given sufficient infrastructure, allows it to be implemented on many UNIX-like systems. The major focus, initially, is systems running the Linux 2.6 series kernels.


1.2. Acknowledgements

Havoc Pennington's article ''Making Hardware Just Work'' motivated this work. The specification and software would not exist without all the useful ideas, suggestions, comments and patches from the Free Desktop and HAL mailing lists.

All trademarks mentioned belong to their respective owners.


1.3. Architecture of HAL

The HAL consists of a number of components as outlined in the diagram below. Note that this diagram is high-level and doesn't capture implementation details.

Details on each component

  • HAL daemon

    A system-wide daemon that maintains a persistent database of device objects. The daemon is also responsible for merging information from the device information file repository and managing the life cycle of device objects. The HAL daemon also contains detection and monitoring code for buses (such as PCI and USB buses) and devices (such as networking and storage devices). The HAL daemon notifies system level components through callouts and session level components using the D-BUS interface.

  • Applications

    This represents the end consumers of the HAL and comprises both applications that need to search for a device, but also (existing) device specific libraries and/or services that provide access to devices. Specifically, the application or device library can obtain the ''address'' (the special device file or other details), of the device through HAL, to interact with the device through the kernel as usual.

    In addition, this group include desktop environments such as GNOME or KDE. Specifically, using HAL, desktop environments may include session-level daemons enforcing certain policies when the device database managed by the HAL daemon changes. Such policies may include starting a photo management application when a camera is plugged in, assisting the user in finding driver software and device information files for a new device, displaying link status information about network devices, mounting removable storage and so on.

    Note that several desktop sessions may be active on the same system; it is the responsibility of session-level software to arbitrate the device access between sessions.

  • Callouts

    Callouts are programs invoked when the device object list is modified As such, callouts can be used to maintain system-wide policy (that may be specific to the particular OS) such as changing permissions on device nodes, updating the systemwide /etc/fstab file or configuring the networking subsystem.

The HAL uses D-BUS to provide a ''network API'' to applications. As D-BUS is designed to be language independent, potentially many languages / runtime systems will be able to easily access the services offered by HAL. The D-BUS API is detailed in Section 4.2 . Note that HAL doesn't enforce any policy at all, this is left for desktop environments and operating systems vendors to implement. However, to ensure interoperability between operating systems and desktop environments, recommendations and best practises on how to enforce policy is discussed in Section 4.3 .


1.4. HAL on Linux 2.6

On a Linux 2.6 system HAL is implemented as shown in the diagram below:

Highlights

  • HAL depends on the udev and linux-hotplug packages

  • The diagram shows an example callout program, fstab-sync, that creates/destroys mount points and modifies the /etc/fstab file accordingly whenever storage devices are added or removed.

  • A session-level daemon, *-volume-manager, for mounting storage devices is shown. This piece of software depends on a properly updated /etc/fstab file and a setuid mount(1) binary that allows an unprivileged user to mount devices marked with option user in the /etc/fstab file.

  • The fstab-sync and *-volume-manager programs are only examples on how to enforce policy and are not part of HAL proper. An OS vendor may choose to enforce policy in a different way e.g. he might want to ignore the /etc/fstab file and mount storage volumes in the callout, run a daemon with sufficient privileges or use another setuid mount wrapper. See Section 4.3 for more details.


1.5. Device Objects

It is important to precisely define the term HAL device object. It's actually a bit blurry to define in general, it includes what most UNIX-like systems consider first class objects when it comes to hardware. In particular, a device object should represent the smallest unit of addressable hardware. This means there can be a one-to-many relationship between a physical device and the device objects exported by HAL. Specifically, a multi-function printer, which appear to users as a single device may show up as several device objects; e.g. one HAL device object for each of the printing, scanning, fax and storage interfaces. Conversely, some devices may be implemented such that the HAL device object represent several functional interfaces. HAL is not concerned with this duality of either one-to-many or many-to-one relationships between device objects and the actual iron constituting what users normally understand as a single piece of hardware; a device object represents the smallest addressable unit.

Device objects in HAL are organised on a by-connection basis, e.g. for a given device object X it is possible to find the device object Y where X is attached to Y. This gives structure to the device database of HAL; it is possible to map the devices out in a tree. Further, software emulation devices exported by a kernel, such as SCSI emulation for USB Storage Devices, are also considered device objects in HAL. This implies that kernel specific bits leak into the device object database. However users of HAL won't notice, such device objects are not referenced anywhere in the device objects that users are interested in; they are merely used as glue to build the device tree.

In addition to provide information about what kind of hardware a device object represents (such as a PCI or USB device) and how to address it, HAL merges information about the functional interfaces the OS kernel provides in order to use the device; in most cases this is represented on the device object as a string property with the name of the special device file in /dev. In addition to the special device file, a number of other useful properties are merged. This means that both hardware and functional properties are on the same device object, which is very useful for an application programmer. For example, an application might query HAL for the device object that exports the special device file /dev/input/mouse2 and learn that this is provide by an USB mouse from a certain manufacturer by checking the properties that export the USB vendor and product identifiers. See Section 1.6 and Chapter 2 for details.

On a formal level, a device object is comprised by

  • UDI

    This is an identifier, the Unique Device Identifer, that is unique for a device object - that is, no other device object can have the same UDI at the same time. The UDI is computed using bus-specific information and is meant to be unique across device insertions and independent of the physical port or slot the device may be plugged into.

  • Properties

    Each device object got a set of properties which are key/value pairs. The key is an ASCII string while the value can be one of several types

    • string - UTF8 string

    • strlist - sorted list with UTF8 strings

    • int - 32-bit signed integer

    • uint64 - 64-bit unsigned integer

    • bool - truth value

    • double - IEEE754 double precision floating point number

Properties of a device object carry all the important information about a device object. For organisational reasons properties are also namespaced using ''.'' as a separator.

It can be useful to classify properties into four groups

  • Metadata - Information about how the devices are connected with respect to each other (parent/child relationships), what kind of device it is, what functionality it provides etc.

  • Facts - vendor ID, product ID, disk serial numbers, number of buttons on a mouse, formats accepted by a mp3 player and so on.

  • Usage specific information - Network link status, special device file name, filesystem mount location etc.

  • Policy - How the device is to be used be users; usually defined by the system administrator.

The first category is determined by HAL, the next is merged from either the hardware itself or device information files, the third is intercepted by monitoring the operating system and the last is merged from files that only the system administrator can edit. This specification is concerned with precisely defining several properties; see Chapter 2 and onwards for more information. As a complement to device properties, HAL also provides conditions on HAL device objects. Conditions are used to relay events that are happening on devices which are not easily expressed in properties. This includes events such as ''processor is overheating'' or ''block device unmounted''.

There is a special hal device object referred to as the ''root computer device object''. This device object represent the entire system as a whole and all other devices are either directly or indirectly childs of this device object. It has the UDI /org/freedesktop/Hal/devices/computer.

The fundamental idea about HAL is that all ''interesting'' information about hardware that a desktop application needs, can be obtained by querying HAL. Below is a screenshot of a simple device manager application shipped with HAL called hal-device-manager. This application is communicating with the HAL daemon and displays the tree of device objects. The shown properties are for a device object representing a harddisk.


1.6. Device Capabilities

Mainstream hardware isn't very good at reporting what they are, they only report, at best, how to interact with them. This is a problem; many devices, such as MP3 players or digital still cameras, appear to the operating system as plain USB Mass Storage devices when they in fact are a lot more than just that. The core of the problem is that without external metadata, the operating system and desktop environment will present it to the user as just e.g. a mass storage device.

As HAL is concerned with merging of external metadata, through e.g. device information files, there needs to be some scheme on how to record what the device actually is. This is achieved by two textual properties, info.category and info.capabilities. The former describes what the device is (as a single alphanumeric keyword) and the latter describes what the device does (as a number of alphanumeric keywords separated by whitespace). The keywords available for use is defined in this document; we'll refer to them in following simply as capabilities.

HAL itself, assigns capabilities on device detection time by inspecting the device class (if available, it depends on the bus type) and looking at information from the operating system (most OS'es have a concept of device classes). At this time the category is also determined by selecting the most prominent capability. However, both capabilities and category can be overridden by either device information files or callouts. This gives maximum flexibility, while maintaining a base level of capability detection.

The idea of HAL is that existing device capability specific libraries (such as libghoto2), would advertise what kind of HAL capabilities they are able to handle. As this happens over time, this specification will grow to precisely define what a device with a given capability is supposed to do and what library, or service, the application programmer can use to access the device.

Having a capability also means that part of the property namespace, prefixed with the capability name, will be populated with more specific information about the capability. Indeed, some properties may even be required such that applications and device libraries have something to expect. For instance, the capability for being a MP3 player may require properties defining what audio formats the device support, whether it support recording of audio, and how to interact with the device. For example, the latter may specify ''USB Storage Device'' or ''proprietary protocol, use libfooplayer''.

Just as device objects can appear and disappear at any time (e.g. when a device is plugged in respectively removed), capabilities can also appear and disappear - one example of this happening is when device drivers are loaded and unloaded.

Finally, capabilities have an inheritance scheme, e.g. if a device has a capability foo.bar, it must also have the capability foo.


1.7. Using devices

While the HAL daemon provides generic operations that apply to all devices (though some may be no-ops), HAL is not concerned with providing non-generic device operations. Specifically, one goal of HAL is to integrate with existing and future libraries that target a specific class of devices such as cameras or mp3 players.

For instance, libgphoto2 could be extended such that the application programmer can simply pass the UDI of the camera he wishes to interact with and libghoto2 would then, via D-BUS, acquire the bus-specific information required, the address so to speak, from the HAL daemon, and then interact directly with the hardware.

Another option is to use the existing API of the device library to discover devices (the library would be using HAL under the hood) and provide a function to retrieve the HAL UDI of the device. When the library is built without HAL support this function returns NULL, however, when the UDI is available, then applications using the library can use the UDI both as stable reference to the device and also to extract more information directly from the HAL daemon.


Chapter 2. Device Properties

Properties are arranged in a namespaces using ''.'' as a separator and are key/value pairs. The value may assume different types; currently int32, double, bool, UTF8 strings and UTF8 string lists are supported. The key of a property is always an ASCII string without any whitespace. The properties are updated in real-time.


2.1. Metadata Properties

The section represents properties that aren't tied to either physical or functional characteristics of what the device object represents.


2.1.1. info namespace

The info namespace contain properties that can be considered metadata about device objects. These properties are always available.

Key (type)ValuesMandatoryDescription
info.bus (string) pci, usb, ide_host, ide, block, usb, usbif, scsi_host, scsiYesDescribes what ''physical'' bus the device is connected to
info.udi (string) example: /org/freedesktop/Hal/devices/pci_10ec_8139YesThe HAL unique device id
info.persistent (bool)   No, but required if info.not_available is set to TRUE If this property is set, the device will remain in the the GDL even if the device is unplugged. NOTE: property not implemented yet
info.not_available (bool)  NoThe device is currently not available (it may be unplugged or powered down) NOTE: property not implemented yet
info.capabilities (strlist) example: 'block, storage, storage.cdrom'NoA string list of capabilities describing what the devices does
info.category (string) example: storage.cdromNoThe prominent capability describing what the device is
info.product (string) examples: ''SleekKeyboard'', ''MouseMan 2003'', ''Volume'', ''LS-120 SLIM3 00 UHD Floppy''NoThe name of the device
info.vendor (string) examples: Logitch, MustekNoThe name of the vendor of the device
info.parent (string) example: /org/freedesktop/Hal/devices/ide_1_0Yes, for all non-root device objectsThe UDI of the device object that this device object is connected to.
info.locked (bool)  No If this property is available and set to TRUE it means that a process is using the device that the hal device object in question represents and no other process should attempt to use or configure the device. The lock is only advisory.
info.locked.reason (string) example: ''The optical drive is currently being used to record a CD-RW disc.'' Only available if info.locked is set to TRUE. A localized text suitable for UI display
info.locked.dbus_service (string) example: :1.278 Only available if info.locked is set to TRUE. The base D-BUS service of the process holding the lock.


2.1.2. linux namespace

This namespace is used to store Linux-specific metadata about the device object and is only available on Linux systems.

Key (type)ValuesMandatoryDescription
linux.sysfs_path (string) examples: /sys/block/sda/sda1, /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0Yes (only if available for the device) A fully-qualified path into the sysfs filesystem for the physical device
linux.sysfs_path_device (string)  Yes (only if available for the device) Normally this property assumes the same value as linux.sysfs_path, however for some devices it assumes an alternate location in the sysfs filesystem. It is used internally in HAL
linux.acpi_path (string) example: /proc/acpi/button/power/PWRF, /proc/pmu/battery_0No A fully-qualified path into the procfs filesystem for a device object representing an ACPI abstraction.
linux.driver (string) examples: agpgart-intel, yenta_cardbus, usb, hub, usbhidNoName of the driver bound to this device
linux.kernel_devname (string) example: usb-0000:00:07.2-1.2NoA name used internally in the Linux kernel to identify the device. Used internally in HAL.
linux.is_selinux_enabled (bool)  No; can only appear on the root computer device objectWhether SELinux is enabled on the system


2.2. Physical Properties

In this section properties for device objects that represent physically addressable hardware is described. Availability of these depends on the value of the info.bus property. These properties are not of particular interest to application developers, instead they are useful for libraries and userspace drivers that needs to interact with the device given a UDI. Knowledge of various bus interconnect technologies is assumed for this section to be useful.


2.2.1. pci namespace

This namespace contains properties for device objects representing functions on devices on a PCI bus. These properties are available exactly when info.bus equals pci.

Key (type)ValuesMandatoryDescription
pci.device_class (int) example: 3YesDevice Class
pci.device_subclass (int) example: 0YesPCI Device Sub Class
pci.device_protocol (int) example: 0YesDevice Protocol
pci.product_id (int) example: 0x4c4dYesProduct ID
pci.vendor_id (int) example: 0x1002YesVendor ID
pci.subsys_product_id (int) example: 0x009eYesSubsystem product id
pci.subsys_vendor_id (int) example: 0x1028YesSubsystem vendor id
pci.linux.sysfs_path (string) example: /sys/devices/pci0000:00/0000:00:01/0000:01:00.0Yes (only on Linux) Equals linux.sysfs_path
pci.product (string) Rage Mobility P/M AGP 2xNoName of the product per the PCI database
pci.vendor (string) ATI Technologies IncNoName of the vendor per the PCI database
pci.subsys_product (string) Inspiron 7500NoName of the subsystem product per the PCI database
pci.subsys_vendor (string) Dell Computer CorporationNoName of the subsystem vendor per the PCI database

(FIXME: Some key PCI information (bus, slot, port, function etc.) is missing here)


2.2.2. serial namespace

Device objects that represent serial devices (e.g. /dev/ttyS* or /dev/ttyUSB*).

Key (type)ValuesMandatoryDescription
serial.physical_device (string) example: /org/freedesktop/Hal/devices/pnp_PNP0501 YesUDI of the physical device the serial device is bound to.
serial.device (string) example: /dev/ttyS0YesThe device node to access the OSS device.
serial.port (int) example: 0Yes The port number of the device, based on the number in serial.device
serial.type (string) example: platform, usb, unknownYesThis property defines the type of the serial device.


2.2.3. usb_device namespace

For device objects representing USB devices the property info.bus will be usb_device, and the following properties will be available. Note that the corresponding USB interfaces are represented by separate device objects as children.

Key (type)ValuesMandatoryDescription
usb_device.bus_number (int) example: 1YesThe USB bus the device is attached to
usb_device.configuration_value (int) example: 1YesThe current configuration the USB device is in; starting from 1
usb_device.num_configurations (int) example: 1YesNumber of configurations this USB device can assume
usb_device.device_class (int) example: 0YesUSB Device Class
usb_device.device_subclass (int) example: 0YesUSB Device Sub Class
usb_device.device_protocol (int) example: 0YesUSB Device Protocol
usb_device.is_self_powered (bool) example: falseYesThe device, in the current configuration, is self powered
usb_device.can_wake_up (bool) example: trueYesThe device, in the current configuration, can wake up
usb_device.max_power (int) example: 98YesMax power drain of device, in mA
usb_device.num_interfaces (int) example: 1YesNumber of USB Interfaces in the current configuration
usb_device.num_ports (int) example: 0YesNumber of ports on a hub. Zero for non-hubs
usb_device.port_number (int) example: 1YesThe port number on the parent hub that the device is attached to, starting from 1
usb_device.speed_bcd (int) examples: 0x00150, 0x01200, 0x48000YesSpeed of device, in Mbit/s, in BCD with two decimals
usb_device.version_bcd (int) examples: 0x0100, 0x0110, 0x0200YesUSB version of device in BCD with two decimals
usb_device.level_number (int) example: 2YesDepth in physical USB tree, where the virtual root hub is at depth 0
usb_device.linux.device_number (string) example: 19Yes (only on Linux)USB Device Number as assigned by the Linux kernel
usb_device.linux.parent_number (string) example: 19Yes (only on Linux)Device number of parent device as assigned by the Linux kernel
usb_device.linux.sysfs_path (string) example: /sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1.1Yes (only on Linux) Equals linux.sysfs_path
usb_device.product_id (int) example: 0x3005YesUSB Product ID
usb_device.vendor_id (int) example: 0x04b3YesUSB Vendor ID
usb_device.device_revision_bcd (int) example: 0x0100YesDevice Revision Number encoded in BCD with two decimals
usb_device.serial (string)  NoA string uniquely identifying the instance of the device; ie. it will be different for two devices of the same type. Note that the serial number is broken on some USB devices.
usb_device.product (string) example: IBM USB HUB KEYBOARDNoName of the product per the USB ID Database
usb_device.vendor (string) example: IBM Corp.NoName of the vendor per the USB ID Database


2.2.4. usb namespace

Device objects that represent USB interfaces, ie. when info.bus assumes usb, are represented by the properties below. In addition all the usb_device.* properties from the parent USB device is available in this namespace but only with the usb prefix instead of usb_device.

Key (type)ValuesMandatoryDescription
usb.interface.class (int) example: 0x03YesUSB Class for the interface
usb.interface.subclass (int) example: 0x01YesUSB Sub Class for this interface
usb.interface.protocol (int) example: 0x01YesUSB Protocol for the interface
usb.interface.number (int) example: 1YesNumber of this interface, starting from zero
usb.linux.sysfs_path (string) example: /sys/devices/pci0000:00/0000:00:07.2/usb1/1-1/1-1.1/1-1.1:1.0Yes (only on Linux) Equals linux.sysfs_path


2.2.5. platform namespace

Devices that are built into the platform or present on busses that cannot be properly enumerated (e.g. ISA) are represented by device objects where info.bus equals platform. These kind of devices are commonly, somewhat incorrectly, called legacy devices.

Key (type)ValuesMandatoryDescription
platform.id (string) example: serialYesDevice identification


2.2.6. ide_host namespace

The ide_host namespace is present for device objects where info.bus is set to ide_host. Such device objects represent IDE and ATA host adaptors for harddisks and optical drives as found in the majority of computer systems.

Key (type)ValuesMandatoryDescription
ide_host.number (int)  YesA unique number identifying the IDE host adaptor
ide_host.linux.sysfs_path (string) example: /sys/devices/pci0000:00/0000:00:07.1/ide0Yes (only on Linux) Equals linux.sysfs_path


2.2.7. ide namespace

ATA and IDE drives are represented by device objects where info.bus equals ide. The following properties are available for such device objects.

Key (type)ValuesMandatoryDescription
ide.host (int)  YesCorresponds to ide_host.host_number of the ide_host device that is the parent of this device object
ide.channel (int)  YesIdentifies the IDE channel of the host interface


2.2.8. scsi_host namespace

The scsi_host namespace is present for device objects where info.bus is set to scsi_host. Such device objects represent SCSI host adaptors for SCSI devices as found in some computer systems.

Key (type)ValuesMandatoryDescription
scsi_host.host (int)  YesA unique number identifying the SCSI host adaptor


2.2.9. scsi namespace

SCSI devices are represented by device objects where info.bus equals scsi. The following properties are available for such device objects.

Key (type)ValuesMandatoryDescription
scsi.host (int)  Yes Corresponds to scsi_host.host of the scsi_host device that is the parent of this device object
scsi.bus (int)  YesSCSI channel number
scsi.target (int)  YesSCSI identifier number
scsi.lun (int)  YesSCSI Logical Unit Number
scsi.type (string) Example: diskYesSCSI device type
 cdrom This is a SCSI cdrom device.
 comm This is a SCSI communication device.
 disk This is a SCSI disk device.
 medium_changer This is a SCSI media changer (e.g. for CD/Tape).
 printer This is a SCSI printer.
 processor This is a SCSI processor device.
 raid This is a SCSI raid device.
 scanner This is a SCSI scanner.
 tape This is a SCSI tape device.
 unknown The type of this SCSI device is unknwon.


2.2.10. ieee1394_host namespace

Device objects with info.bus set to ieee1394_host represent IEEE 1394 host adaptors. The following properties are available for such device objects.

Key (type)ValuesMandatoryDescription
ieee1394_host.is_busmgr (bool)  YesTODO
ieee1394_host.is_irn (bool)  YesTODO
ieee1394_host.is_root (bool)  YesTODO
ieee1394_host.node_count (int)  YesTODO
ieee1394_host.nodes_active (int)  YesTODO


2.2.11. ieee1394_node namespace

Device objects with info.bus set to ieee1394_node represent IEEE 1394 nodes on a IEEE 1394 bus. The following properties are available for such device objects.

Key (type)ValuesMandatoryDescription
ieee1394_node.capabilities (int)  YesTODO
ieee1394_node.guid (int)  YesTODO
ieee1394_node.nodeid (int)  YesTODO
ieee1394_node.vendor (int)  YesTODO
ieee1394_node.vendor_id (int)  YesTODO


2.2.12. ieee1394 namespace

Device objects with info.bus set to ieee1394 represent IEEE 1394 devices. The following properties are available for such device objects.

Key (type)ValuesMandatoryDescription
ieee1394.specifier_id (int)  YesTODO


2.2.13. mmc_host namespace

Device objects with info.bus set to mmc_host represent MultiMediaCard or Secure Digital host adaptors. The following properties are available for such device objects.

Key (type)ValuesMandatoryDescription
mmc_host.host (int)  YesA unique number identifying the MMC/SD host adaptor


2.2.14. mmc namespace

Device objects with info.bus set to mmc represent MultiMediaCard or Secure Digital cards. The following properties are available for such device objects.

Key (type)ValuesMandatoryDescription
mmc.cid (string) example: 0150415330303842413a1a8083003a9dYesCard Identification Data register (unique for every card in existence)
mmc.csd (string) example: 005d013213598067b6d9cfff1640002dYesCard Specific Data register
mmc.scr (string) example: 00a5000000410000Only for SD cardsSD Card Register
mmc.rca (int) example: 8083YesCard bus address
mmc.oem (string)  YesCard OEM distributor
mmc.date (string) example: 10/2003YesManufacturing date
mmc.serial (int) example: 0x3a1a8083YesCard serial number
mmc.hwrev (int) example: 4YesHardware revision
mmc.fwrev (int) example: 1YesFirmware revision


2.2.15. ccw namespace

Device objects that represent s390 ccw devices (when info.bus is set to ccw) are represented by the properties below.

Key (type)ValuesMandatoryDescription
ccw.devtype (string) example: 1732/01YesDevice type/model or n/a
ccw.cutype (string) example: 1731/01YesControl unit type/model
ccw.cmb_enable (int) example: 1YesIf channel measurements are enabled
ccw.availability (string) example: goodYesCan be one of 'good', 'boxed', 'no path', or 'no device'
ccw.online (int) example: 1YesOnline status
ccw.bus_id (string) example: 0.0.f588YesThe device's bus id in sysfs
ccw.subchannel.pim (int) example: 0x80Nopath installed mask
ccw.subchannel.pam (int) example: 0x80Nopath available mask
ccw.subchannel.pom (int) example: 0xffNopath operational mask
ccw.subchannel.chpid0..7 (int) example: 0x40Nochannel path ids

The following properties describe ccw devices where linux.driver is either dasd-eckd or dasd-fba.

Key (type)ValuesMandatoryDescription
ccw.dasd.use_diag (int) example: 0YesIf the device driver shall use diagnose calls to access the device
ccw.dasd.readonly (int) example: 0YesIf the device can only be accessed readonly
ccw.dasd.discipline (string) example: ECKDNoThe dasd discipline used to access the device

The following properties describe ccw devices where linux.driver is zfcp. They are only present when ccw.online = 1.

Key (type)ValuesMandatoryDescription
ccw.zfcp.in_recovery (int) example: 0YesShows whether the adapter is currently in recovery
ccw.zfcp.failed (int) example: 0YesShows whether the adapter is in failed state

The following properties describe ccw devices where linux.driver is of the form tape_3xxx .

Key (type)ValuesMandatoryDescription
ccw.tape.state (string) example: IN_USEYesThe current status of the tape
ccw.tape.operation (string) example: REWYesA three-letter mnemonic of the current tape operation
ccw.tape.medium_state (string) example: no mediumNo If ccw.online = 1, shows whether a tape is loaded
ccw.tape.blocksize (int) example: 512No If ccw.online = 1, shows the blocksize used for reads and writes to the tape

The following properties describe ccw devices where linux.driver is 3270.

Key (type)ValuesMandatoryDescription
ccw.3270.model (int) example: 3YesThe model of the device, determining rows and columns
ccw.3270.rows (int) example: 32YesThe number of rows
ccw.3270.columns (int) example: 80YesThe number of columns


2.2.16. ccwgroup namespace

Device objects that represent groups of ccw devices (when info.bus is set to ccwgroup have the properties specified below.

Key (type)ValuesMandatoryDescription
ccwgroup.online (int) example: 1YesOnline status
ccwgroup.bus_id (string) example: 0.0.f588YesThe device's bus id in sysfs

The following properties describe ccwgroup devices where linux.driver is qeth.

Key (type)ValuesMandatoryDescription
ccwgroup.qeth.large_send (string) example: TSONoWhether large send is provided. Can be "no", "EDDP" (software) or "TSO" (hardware).
ccwgroup.qeth.card_type (string) example: OSD_1000YesType of the card
ccwgroup.qeth.checksumming (string) example: sw checksummingNoThe method used to checksum incoming packets
ccwgroup.qeth.canonical_macaddr (int) example: 0NoSpecifies the token ring macaddress format. Not valid in layer2 mode and for ethernet devices.
ccwgroup.qeth.broadcast_mode (string) example: broadcast_allringsNoThe scope of token ring broadcasts. Not valid in layer2 mode and for ethernet devices.
ccwgroup.qeth.fake_broadcast (int) example: 0NoWhether to fake broadcast capability. Not valid in layer2 mode.
ccwgroup.qeth.fake_ll (int) example: 0NoWhether to add a faked link level header to packets. Not valid in layer2 mode.
ccwgroup.qeth.layer2 (int) example: 0NoWhether the card operates in layer 2 mode
ccwgroup.qeth.portname (string) example: OSAPORTNoThe port name which has been specified for the card
ccwgroup.qeth.portno (int) example: 0NoThe relative port number on the card
ccwgroup.qeth.buffer_count (int) example: 16YesNumber of inbound buffers used
ccwgroup.qeth.add_hhlen (int) example: 0NoHow much additional space is provided in the hardware header in skbs in front of packets
ccwgroup.qeth.priority_queueing (string) example: always queue 2NoWhich priority queueing algorithm is to be used
ccwgroup.qeth.route4 (string) example: noNoWhether the card has a routing functionality for ipv4. Not valid in layer2 mode.
ccwgroup.qeth.route6 (string) example: noNoWhether the card has a routing functionality for ipv6. Not valid in layer2 mode.
ccwgroup.qeth.state (string) example: UP (LAN ONLINE)YesThe device's current state

The following properties describe ccwgroup devices where linux.driver is ctc.

Key (type)ValuesMandatoryDescription
ccwgroup.ctc.protocol (int) example: 0YesThe protocol/method used by the connection
ccwgroup.ctc.type (string) example: CTC/AYesThe device/connection type
ccwgroup.ctc.buffer (int) example: 32768NoThe maximum buffer size of the connection

The following properties describe ccwgroup devices where linux.driver is lcs.

Key (type)ValuesMandatoryDescription
ccwgroup.lcs.portnumber (int) example: 0YesThe port on the card that is used
ccwgroup.lcs.type (string) example: OSA LCS cardYesThe type of the card
ccwgroup.lcs.lancmd_timeout (int) example: 5YesThe timeout value for LAN commands in seconds

The following properties describe ccwgroup devices where linux.driver is claw.

Key (type)ValuesMandatoryDescription
ccwgroup.claw.api_type (string)  YesDetermines the packing algorithm for outgoing pakets (matching the remote peer)
 IP Using the IP protocol
 PACKED Using an enhanced packing algorithm
 TCPIP Using the TCP/IP protocol
ccwgroup.claw.adapter_name (string) example: RS1YesThe host name of the remote communication peer.
ccwgroup.claw.host_name (string) example: LNX1YesThe host name of the local adapter.
ccwgroup.claw.read_buffer (int) example: 4YesThe number of read buffers allocated
ccwgroup.claw.write_buffer (int) example: 5YesThe number of write buffers allocated


2.2.17. iucv namespace

Device objects with info.bus set to iucv are using the "Intra-User Comminication Vehicle" and are described by the following properties.

Key (type)ValuesMandatoryDescription
iucv.bus_id (string) example: netiucv0YesThe device's bus id in sysfs

The following properties describe iucv devices where linux.driver is netiucv.

Key (type)ValuesMandatoryDescription
iucv.netiucv.user (string) example: linux12YesThe guest name of the connection's target
iucv.netiucv.buffer (int) example: 32768YesThe maximum buffer size of the connection


2.2.18. block namespace

Device objects representing addressable block devices, such as drives and partitions, will have info.bus set to block and will export a number of properties in the block namespace.

Key (type)ValuesMandatoryDescription
block.device (string) example: /dev/sda YesSpecial device file to interact with the block device
block.major (int) example: 8YesMajor number of special file to interact with the device
block.minor (int) example: 1YesMinor number of special file to interact with the device
block.is_volume (bool)  YesTrue only when the block device is a volume that can be mounted into the file system. In this case the volume capability will be set and thus, properties, in the volume namespace are available.
block.no_partitions (bool)  YesFor toplevel block devices, this is TRUE only when no known partition tables have been found on the media (In this case, if the storage device contain a file system it will be accessible using the same special device file as the one for this device object and the device object representing the filesystem will appear as a separate device object as a child). For the child, that is when block.is_volume is true, this property is TRUE exactly when it was created for a storage device with the storage.no_partitions_hint set to TRUE.
block.have_scanned (bool)  Yes An internal property used by HAL to specify whether a top level block device have already been scanned for filesystems.


2.2.19. xen namespace

Device objects representing virtual devices under the Xen Virtual Machine Monitor, such as frontend network or block devices, will have info.bus set to block and will export a number of properties in then xen namespace.

Key (type)ValuesMandatoryDescription
xen.bus_id (string)example: vif-0 YesThe XenBus ID of the device
xen.path (string)example: device/vif/0 YesThe XenBus path of the device
xen.type (string)example: vifYesThe type of Xen device


2.3. Functional Properties

The section describe functional properties of device objects, that is, properties that are merged onto device objects representing physically addressable hardware. In most circumstances such properties stem from a kernel level driver attached to the device represented by the device object, however, as HAL can merge properties from anywhere, they may have been merged from device information files or callouts.


2.3.1. volume namespace

This namespace is for device objects that represent storage devices with a filesystem that can be mounted. Such device objects will have the capability volume and they will export the properties below. Note that device objects can only have the volume capability if they already have the capability block and the property block.is_volume set to TRUE.

Key (type)ValuesMandatoryDescription
volume.ignore (bool)  YesThis is a hint to software higher in the stack that this volume should be ignored. If TRUE, the volume should be invisible in the UI and mount wrappers should refuse to mount it on behalf on an unprivileged user. This is useful for hiding e.g. firmware partitions (e.g. bootstrap on Mac's) and OS reinstall partitions on e.g. OEM systems.
volume.is_mounted (bool)  YesThis property is TRUE if and only if the volume is mounted
volume.is_mounted_read_only (bool)  YesThis property is TRUE if and only if the volume is mounted and the volume's file-system is read-only.
volume.mount_point (string) example: /media/compact_flash1 Yes (is blank only when volume.is_mounted is FALSE)A fully qualified path to the mount point of the volume
volume.fsusage (string) example: filesystemYes This property specifies the expected usage of the volume
 filesystem The volume is a mountable filesystem
 partitiontable  The volume contains a partitiontable.
 raid The volume is a member of a raid set and not mountable
 other The volume is not mountable like a swap partition
 unused The volume is marked a unused or free
volume.fstype (string) examples: ext3, vfatYes (is blank if the type is unknown)The specific type of either the file system or what the volume is used for, cf. volume.fsusage
volume.fsversion (string) example: FAT32 Version number or subtype of the filesystem
volume.label (string) example: 'Fedora Core 1.90' Yes (is blank if no label is found)The label of the volume
volume.uuid (string) example: 4060-6C11Yes (is blank if no UUID is found)The Universal Unique Identifer for the volume
volume.is_disc (bool)  YesIf the volume stems from an optical disc, this property is true and the device object will also have the capability volume.disc
volume.block_size (string)  No The block size of the volume
volume.num_blocks (string)  No Number of blocks on the volume
volume.size (uint64)  No Size of the volume in bytes
volume.is_partition (bool)  Yes If the volume stems from a partition on e.g. a hard disk, this property is set to TRUE.
volume.linux.is_device_mapper (bool)  Yes, but only on Linux If the volume stems from the Linux Device Mapper this property is set to TRUE.
volume.partition.number (int)   If, and only if, volume.is_partition is set to TRUE. The number of the partition.
volume.partition.label (string)   If, and only if, volume.is_partition is set to TRUE. Label of partition. Only available for "apm" and "gpt" partition tables. Note that this is not the same as the file system label defined in volume.label.
volume.partition.uuid (string)   If, and only if, volume.is_partition is set to TRUE. The UUID or GUID of the partition table entry. Only available for "gpt" partition tables.
volume.partition.scheme (string)   If, and only if, volume.is_partition is set to TRUE. The scheme of the partition table this entry is part of. Note that this is not necessarily the same as storage.partitioning_scheme as some partition tables can embed other partition tables.
 mbr  Master Boot Record
 embr  Extended Master Boot Record
 gpt  GUID Partition Table as defined by EFI
 apm  Apple Partition Map
volume.partition.type (string)   If, and only if, volume.is_partition is set to TRUE. The type of the partition table entry. Depends on volume.partition.scheme.
 mbr and embr entries  The hexadecimal encoding of the 8-bit partition type, see http://www.win.tue.nl/~aeb/partitions/partition_types-1.html for a list. For example the Linux partition type is represented as the string "0x83".
 gpt entries  The GUID encoded as a string. See http://en.wikipedia.org/wiki/GUID_Partition_Table for a list of well-known GUID's.
 apm entries  Defined in http://developer.apple.com/documentation/mac/Devices/Devices-126.html. Also note that for FAT file systems, it appears that "DOS_FAT_32", "DOS_FAT_16" and "DOS_FAT_12" are also recognized under Mac OS X (I've tested this too) cf. http://lists.apple.com/archives/Darwin-drivers/2003/May/msg00021.html
volume.partition.flags (strlist)   If, and only if, volume.is_partition is set to TRUE. Flags conveying specific information about the partition entry. Dependent on the partitioning scheme.
 mbr and embr entries  Only one flag, "boot", is defined. This is used by some BIOS'es and boot loaders to populate a boot menu. It means that a partition is bootable.
 gpt entries  Only the flag "required" is recognized. This corresponds to bit 0 of the attibutes (at offset 48), meaning "Required for the platform to function. The system cannot function normally if this partition is removed. This partition should be considered as part of the hardware of the system, and if it is removed the system may not boot. It may contain diagnostics, recovery tools, or other code or data that is critical to the functioning of a system independent of any OS."
 apm entries  The following flags are recognized: "allocated" if the partition is already allocated; and "in_use" if the partition is in use; may be cleared after a system reset; and "boot" if partition contains valid boot information; and "allow_read" if partition allows reading; and "allow_write"; if partition allows writing; and "boot_code_is_pic"; if boot code is position independent
volume.partition.media_size (uint64) example: 500107862016 If, and only if, volume.is_partition is set to TRUE. If available, size of the current media or the fixed disk in the storage device.
volume.partition.start (uint64) example: 32256 If, and only if, volume.is_partition is set to TRUE. If available, the offset where the physical partition starts on the media or the fixed disk in the storage device.

Device objects with this capability may emit the following device conditions

Condition NameParametersExampleDescription
VolumeMount block.device (string), volume.mount_point (string) /dev/sda1, /media/compact_flash Emitted when a volume is mounted
VolumeUnmount block.device (string), volume.mount_point (string) /dev/sda1, /media/compact_flash Emitted when a volume is unmounted
VolumeUnmountForced block.device (string), volume.mount_point (string) /dev/sda1, /media/compact_flash Emitted when a volume is forcibly unmounted because the media backing the volume was removed.


2.3.2. system namespace

This namespace is found on the toplevel "Computer" device, and represents information about the system and the currently running kernel.

Key (type)ValuesMandatoryDescription
system.kernel.name (string) example: LinuxNo The name of the kernel, usually the equivalent of uname -s.
system.kernel.version (string) example: 2.6.5-7.104-defaultNo The version of the currently running kernel. Usually the equivalent of uname -r.
system.kernel.machine (string) example: i686No The "machine hardware name" of the currently running kernel. Usually the equivalent of uname -m.
system.formfactor (string) example: laptop, desktop, server, unknownYes The formfactor of the system. Usually the equivalent of smbios.chassis.type or set from information about ACPI/APM/PMU properties.
system.vendor (string)  No The name of the manufacturer of the machine. Usually the equivalent of smbios.system.manufacturer.
system.product (string)  No The product name of the machine. Usually the equivalent of smbios.system.product and smbios.system.version.


2.3.3. volume.disc namespace

This namespace is for device objects that represent optical discs, e.g. device objects with the capability volume.disc. Such device objects will also have the capability volume.

Key (type)ValuesMandatoryDescription
volume.disc.has_audio (bool)  YesIs true only if the disc contains audio
volume.disc.has_data (bool)  YesIs true only if the disc contains data
volume.disc.is_vcd (bool)  YesIs true only if the disc is a Video CD
volume.disc.is_svcd (bool)  YesIs true only if the disc is a Super Video CD
volume.disc.is_videodvd (bool)  YesIs true only if the disc is a Video DVD
volume.disc.is_appendable (bool)  YesIs true only if it's possible to write additional data
volume.disc.is_blank (bool)  YesIs true only if the disc is blank
volume.disc.is_rewritable (bool)  YesIs true only if the disc is rewritable
volume.disc.capacity (uint64)  NoCapacity of disc, in bytes
volume.disc.type (string)  YesThis property specifies the physical type of the disc
 cd_rom CD-ROM disc
 cd_r CD-R disc
 cd_rw CD-RW disc
 dvd_rom DVD-ROM disc
 dvd_ram DVD-RAM disc
 dvd_r DVD-R disc
 dvd_rw DVD-RW disc
 dvd_plus_r DVD+R disc
 dvd_plus_rw DVD+RW disc
 bd_rom BD-ROM disc
 bd_r BD-R disc
 bd_re BD-RE disc
 hddvd_rom HD DVD-ROM disc
 hddvd_r HD DVD-R disc
 hddvd_rw HD DVD-Rewritable disc
 unknown Unknown type or lack of support from drive to determine the type


2.3.4. storage namespace

This namespace is used to describe physical storage devices and their capabilities. Such device objects will have the capability storage and they will export the properties below. Note that device objects can only have the storage capability if they already got capability block and the property block.is_volume set to FALSE. One significant between the storage and block namespace is that the properties exported in the storage represents constant vital product information, whereas the properties in the block namespace represent variable system-dependent information.

Key (type)ValuesMandatoryDescription
storage.bus (string)  YesPhysical interface the storage device is attached to
 ide IDE or ATA interface
 usb USB interface
 ieee1394 IEEE 1394 interface
 scsi SCSI interface
 sata SATA interface
 platform Legacy device that is part of the platform
    
storage.drive_type (string)  Yes The type of the drive. Note that it may not be possible to probe for some of these properties so in some cases memory card readers may appear as harddisks. Device information files can be used to override this value.
 disk The device is a harddisk
 cdrom  The device is an optical drive. The device object will also have the capability storage.cdrom in this case.
 floppy The device is a floppy disk drive
 tape The device is a tape drive
 compact_flash The device is a card reader for Compact Flash memory cards
 memory_stick The device is a card reader for MemoryStick memory cards
 smart_media The device is a card reader for SmartMedia memory cards
 sd_mmc The device is a card reader for SecureDigital/MultiMediaCard memory cards
    
storage.removable (bool)  YesMedia can be removed from the storage device
storage.removable.media_available (bool)  Yestrue, if and only if, media have been detected in storage device
storage.removable.media_size (uint64)  YesSize of media in storage device. Available only if media have been detected in storage device.
storage.partitioning_scheme (string)  Only when media is inserted and is partitionedThe partitioning scheme of the media.
 mbr Master Boot Record partitioning scheme used in most PC's
 gpt GUID Partitioning Table as defined by UEFI
 apm Apple Partition Map, used in non-Intel Apple computers
storage.size (uint64)  Nosize in bytes of the storage device - only meaningful if storage.removable is FALSE
storage.requires_eject (bool)  YesThe eject ioctl is required to properly eject the media
storage.hotpluggable (bool)  YesThe storage device can be removed while the system is running
storage.media_check_enabled (bool)  YesIf this property is set to FALSE then HAL will not continuosly poll for media changes.
storage.automount_enabled_hint (bool)  YesThis property is a hint to desktop file managers that they shouldn't automount volumes of the storage device when they appear.
storage.no_partitions_hint (bool)  Yes This property is a hint to programs that maintain the /etc/fstab file to signal, when TRUE, that the storage drive (such as floppy or optical drives) is used for media with no partition table so an entry can be added ahead of media insertion time. Note that this is only a hint; media may be inserted that has partition tables that the kernel may respect. Conversely, when this is FALSE media without partition tables may be inserted (an example is a Compact Flash card; this media is normally formatted with a PC style partition table and a single FAT partition. However, it may be formatted with just a single FAT partition and no partition table).
storage.physical_device (string)  Yes This contains the UDI of the device object representing the physical device or blank if there is no such device (which is TRUE for legacy devices such as x86 floppy drives). Additionally, a number of properties are merged from that device object. Specifically, all properties prefixed with storage and, if the physical device has several storage ports, storage_lunX (where X is number of the port starting from zero) are merged and will have the prefix storage. See Section 3.1.3 for an example.
storage.model (string)  YesThe name of the drive
storage.vendor (string)  YesThe vendor of the drive
storage.serial (string)  NoThe serial number of the drive
storage.firmware_revision (string)  NoThe revision of the firmware of the drive
storage.icon.drive (string)  No Name of icon to use for displaying the drive. The name must comply with freedesktop.org icon-theme specification and must not be an absolute path. This property exists such that e.g. OEM's can install icons in /usr/share/icons/hicolor a device information file matching their device.
storage.icon.volume (string)  No Name of icon to use for displaying volumes from the drive. The name must comply with freedesktop.org icon-theme specification and must not be an absolute path. This property exists such that e.g. OEM's can install icons in /usr/share/icons/hicolor a device information file matching their device.


2.3.5. storage.cdrom namespace

This namespace is used to describe optical storage drives and their capabilities.Such device objects will have the capability storage.cdrom and they will export the properties below. Note that device objects can only have the storage.cdrom capability if they already got the capability storage.

Key (type)ValuesMandatoryDescription
storage.cdrom.cdr (bool)  YesTRUE when the optical drive can write CD-R discs
storage.cdrom.cdrw (bool)  YesTRUE when the optical drive can blank and write to CD-RW discs
storage.cdrom.dvd (bool)  YesTRUE when the optical drive can read DVD-ROM discs
storage.cdrom.dvdr (bool)  YesTRUE when the optical drive can write to DVD-R discs
storage.cdrom.dvdrw (bool)  YesTRUE when the optical drive can blank and write to DVD-RW discs
storage.cdrom.dvdram (bool)  YesTRUE when the optical drive can write to DVD-RAM discs
storage.cdrom.dvdplusr (bool)  YesTRUE when the optical drive can write to DVD+R discs
storage.cdrom.dvdplusrw (bool)  YesTRUE when the optical drive can blank and write to DVD+RW discs
storage.cdrom.dvdplusrwdl (bool)  YesTRUE when the optical drive can blank and write to DVD+RW Dual-Layer discs
storage.cdrom.dvdplusrdl (bool)  YesTRUE when the optical drive can write to DVD+R Dual-Layer discs
storage.cdrom.bd (bool)  YesTRUE when the optical drive can read Blu-ray ROM discs
storage.cdrom.bdr (bool)  YesTRUE when the optical drive can write to Blu-ray Recordable discs
storage.cdrom.bdre (bool)  YesTRUE when the optical drive can write to Blu-ray Rewritable discs
storage.cdrom.hddvd (bool)  YesTRUE when the optical drive can read Read-only HD DVD discs
storage.cdrom.hddvdr (bool)  YesTRUE when the optical drive can write to Write-once HD DVD discs
storage.cdrom.hddvdrw (bool)  YesTRUE when the optical drive can write to Rewritable HD DVD discs
storage.cdrom.support_media_changed (bool)  YesTRUE if the drive can generate media changed events
storage.cdrom.read_speed (int)  YesThe maximum reading speed, in kb/s
storage.cdrom.write_speed (int)  YesThe maximum writing speed, in kb/s
storage.cdrom.write_speeds (strlist)  NoBy the device supported write speeds in kb/s


2.3.6. net namespace

This namespace is used to describe networking devices and their capabilities.Such device objects will have the capability net and they will export the properties below. This namespace only describe the generic aspect of networking devices; specific networking technologies such as IEEE 802.3 and IEEE 802.11 have separate namespaces.

Key (type)ValuesMandatoryDescription
net.address (string)  YesHardware address as a string. Is hardware dependant
net.arp_proto_hw_id (string)  YesARP protocol hardware identifier
net.interface (string)  YesName of the interface; may change if an interface is renamed
net.interface_up (bool)  NoWhether the interface is up
net.linux.ifindex (string)  Yes (only on Linux)Index of the interface
net.physical_device (string)  YesUDI of the physical device the network device is bound to.
net.media (string) example: EthernetYesTextual description of the networking media


2.3.7. net.80203 namespace

Ethernet networking devices is described in this namespace for device objects with the capability net.80203. Note that device objects can only have the net.80203 capability if they already have the capability net.

Key (type)ValuesMandatoryDescription
net.80203.link (bool)   Only if the net.80203 capability is set and net.interface_up is TRUE. True if the ethernet adaptor is connected to a another transceiver. NOTE: property not implemented yet.
net.80203.rate (uint64) example: 100000000 Only if the net.80203 capability is set and net.80203.link is TRUE. Bandwidth of connection, in bits/s. NOTE: property not implemented yet.
net.80203.mac_address (uint64) example: 0x0010605d8ef4 Only if the net.80203 is set 48-bit address


2.3.8. net.80211 namespace

Wireless ethernet networking devices is described in this namespace for device objects with the capability net.80211. Note that device objects can only have the net.80211 capability if they already have the capability net.

Key (type)ValuesMandatoryDescription
net.80211.mac_address (uint64) example: 0x0010605d8ef4 Only if the net.80211 capability is set 48-bit address


2.3.9. net.irda namespace

IrDA (Infrared Data Association) Networking devices are described in this namespace for device objects with the capability net.irda. Note that device objects can only have the net.irda capability if they already have the capability net.


2.3.10. net.80211control namespace

Control devices for Wireless ethernet networking devices are described in this namespace for device objects with the capability net.80211control. Note that device objects can only have the net.80211control capability if they already have the capability net. Warning: You should know what you do if you touch this devices. They are not always stable and can cause (kernel) crashes (on linux).


2.3.11. input namespace

This namespace is concerned with human input devices such as keyboards, mice, pointing devices and game controllers. If a device object has the capability input then the following properties are available

Key (type)ValuesMandatoryDescription
input.device (string)  YesSpecial device file for recieving input events


2.3.12. pcmcia_socket namespace

Device objects with the capability pcmcia_socket represent bridge devices (the actual bus of the device may differ) that PCMCIA cards can be attached to. The following properties are available.

Key (type)ValuesMandatoryDescription
pcmcia_socket.number (int)  YesPCMCIA socket number, starting from zero


2.3.13. printer namespace

Device objects with the capability printer represent printers. The following properties are available.

Key (type)ValuesMandatoryDescription
printer.device (string)  YesTODO
printer.vendor (string)  YesTODO
printer.product (string)  YesTODO
printer.serial (string)  YesTODO
printer.description (string)  YesTODO
printer.commandset (strlist)  NoList of supported commands / printer languages.


2.3.14. portable_audio_player namespace

Device objects with the capability portable_audio_player represent portable audio players that can be attached to a computer to exchange files. They can also playback audio. Sometimes they can also record audio. This capability can't, in general, be reliably probed from the hardware so the information needs to be merged from either device information files or callouts. Therefore this capability should be merged on the appropriate device object that represents the addressable piece of hardware that is the portable music player; for USB devices this would be the device object representing the appropriate USB interface. The following properties are available:

Key (type)ValuesMandatoryDescription
portable_audio_player.access_method (string)  YesThis property defines how the device is accessed
 storage  The device is accessed as a Mass Storage device through a kernel driver. Application Developers should descent down the device object tree to find the device object of capability storage in order to access the device.
 user  The device is accessed from userspace through a userspace driver.
    
portable_audio_player.output_formats (strlist) example: audio/mpeg audio/x-ms-wmaYes A string list of MIME-types representing the kind of audio formats that the device can play back
portable_audio_player.input_formats (strlist) example: audio/x-wavYes A string list of MIME-types representing the kind of audio formats that the device can record. If empty, it means that the device is not capable of recording.
portable_audio_player.folder_depth (int) example: 1 (If the device only supports one sub-folder)No If portable_audio_player.access_method = "storage", this tells applications exactly how deep of directory hierarchies files should be placed in. If all files are put in a sub-folder (with the audio_folders property), only the depth within that sub-folder should be entered here. If the device does not have a limit, do not set this property.
portable_audio_player.audio_folders (strlist) example: music/ voice/ linein/No If portable_audio_player.access_method = "storage", this may contain a string list of folders in which music can be found. Paths are relative to the mount point of the device. If there is one or more entry in this property, the first one is where files will be written to by applications. Do not enter a folder and a parent of that folder. If the device places files in its root directory, then do not set this property.
portable_audio_player.playlist_format (strlist) example: audio/x-mpegurl audio/x-somethingelseNo A string list of the MIME-type of the playlist formats accepted by this device. Leave blank if none.
portable_audio_player.playlist_path (string) examples: playlists/%File or Playlist.m3uNo Set to the path to which playlists should be written. Leave blank if playlist files are not supported. If the device supports a single playlist with a specific name/path, set this to the path relative to the mount point that it should be saved to. If it supports multiple playlists, use the %File variable as needed. Applications are responsible for substituting %File with the desired playlist file name, noting that it's use in this string is optional.


2.3.15. alsa namespace

Device objects with the capability alsa represent all the streams available through ALSA on a soundcard.

Key (type)ValuesMandatoryDescription
alsa.card (int)  Yes Card number in system as registered by ALSA.
alsa.card_id (string) Examples: I82801DBICH4, MP3 No Textual description of the card.
alsa.device (int)  Yes Device number assigned by ALSA for a current card.
alsa.device_file (string)  Yes The device node to access the ALSA device.
alsa.device_id (string) Examples: Intel 82801DB-ICH4 MIC2 ADC No Textual description of the specific device for a card
alsa.device_pcm_class (string)  No The PCM class of the device.
 generic  A standard PCM sound device (SND_PCM_CLASS_GENERIC).
 multi  A multichannel device PCM sound device (SND_PCM_CLASS_MULTI) which e.g. contains a generic and a modem device.
 digitizer  A PCM digitizer device (SND_PCM_CLASS_DIGITIZER).
 modem  A PCM modem device (SND_PCM_CLASS_MODEM).
 unknown  The value is 'unknown' if the kernel provide no information about the PCM device class of the device (e.g. the file pcm_class is missing).
 none  The value is 'none' if this there is no PCM class for this device.
alsa.physical_device (string)  Yes UDI of the physical device the ALSA device is bound to.
alsa.type (string)  Yes The type of the stream.
  control   Stream is control device.
  capture   Stream is capture device.
  playback   Stream is playback device.
  unknown   The type of the device is unknown.
  hw_specific   This is a hardware specific device. The driver can use it freely for purposes that are not covered by standard ALSA API.
  timer   Stream is the global ALSA timer device. This means, the device is for all ALSA devices/cards.
  sequencer   Stream is the global ALSA sequencer device. This means, the device is for all ALSA devices/cards.
  unknown   Stream is unknown device.


2.3.16. oss namespace

Device objects with the capability oss represent all the streams available through OSS on a soundcard. OSS devices could be emulated by ALSA.

Note: All OSS devices, except the global devices, are only added if the kernel supports links from oss device to physical device in sysfs. For a patch see: http://thread.gmane.org/gmane.comp.freedesktop.hal/2862.

Key (type)ValuesMandatoryDescription
oss.card (int)  Yes Card number in system as registered by OSS (and/or ALSA).
oss.card_id (string) Examples: I82801DBICH4, MP3 No Textual description of the card.
oss.device (int)  Yes Device number assigned by OSS/ALSA for a current card.
oss.device_file (string)  Yes The device node to access the OSS device.
oss.device_id (string) Examples: Intel 82801DB-ICH4 MIC2 ADC No Textual description of the specific device for a card
oss.physical_device (string)  Yes UDI of the physical device the OSS device is bound to.
oss.type (string)  Yes The type of the stream.
  mixer   Stream is control/mixer device.
  pcm   Stream is PCM device.
  midi   Stream is MIDI device.
  sequencer   Stream is a global OSS sequencer device. This means, the device is for all OSS devices/cards.
  unknown   Stream is unknown device.


2.3.17. camera namespace

Device objects with the capability camera represent digital still cameras that can be attached to a computer to exchange files. This does not include card readers for memory cards used for cameras. This capability can't, in general, be reliably probed from the hardware so the information needs to be merged from either device information files or callouts. Therefore this capability should be merged on the appropriate device object that represents the addressable piece of hardware that is the digital still camera; for USB devices this would be the device object representing the appropriate USB interface. The following properties are available:

Key (type)ValuesMandatoryDescription
camera.access_method (string)  YesThis property defines how the device is accessed
 storage  The device is accessed as a Mass Storage device through a kernel driver. Application Developers should descent down the device object tree to find the device object of capability storage in order to access the device.
 user  The device is accessed from userspace through a userspace driver.
    
camera.libgphoto2.support (bool)  No If true, the device is supported by a userspace driver from the libgphoto2 project.


2.3.18. laptop_panel namespace

Device objects with the capability laptop_panel represent devices capable of changing the brightness of the display.

Key (type)ValuesMandatoryDescription
laptop_panel.num_levels (int)  Yes The brightness levels supported by the adaptor.
laptop_panel.access_method (string)  Yes The access method to use in scripts, e.g. pmu, toshiba, ibm, sony.
laptop_panel.brightness_in_hardware (bool)  No On some laptops, the brightness control is all done in hardware but the hardware also synthesizes keypresses when the brightness is changed. If this key is set true, then any power manager software should not attempt to set any new values on brightness keypress, as it may cause the panel to flash uncontrollably.

The following methods exist on the interface org.freedesktop.Hal.Device.LaptopPanel.

Method (parameter types)ParametersMandatoryDescription
SetBrightness (integer) The hardware brightness state, which should be between 0 and laptop_panel.num_levels - 1. No This method adjusts the brightness on an laptop screen. The values are returned as hardware values rather than percentages as we cannot easily to floating point rounding in shell code and therefore use the raw values to prevent integer rounding errors.
integer GetBrightness (void) Returns the hardware brightness state, which should be between 0 and laptop_panel.num_levels - 1. No This method gets the hardware brightness of the laptop screen, which we may need to do fairly regually on hardware that changes the values in hardware without a software event.


2.3.19. video_adapter_pm namespace

Device objects with the capability video_adapter_pm represent video adapters that need to be suspended or resumed in device specific ways.

Key (type)ValuesMandatoryDescription
video_adapter_pm.s3_bios (bool)  NoUse the S3_BIOS kernel command for suspend.
video_adapter_pm.s3_mode (bool)  NoUse the S3_MODE kernel command for suspend.
video_adapter_pm.dpms_suspend (bool)  NoSuspend the video card via DPMS.
video_adapter_pm.vga_mode_3 (bool)  NoReset the VGA text mode to mode 3 on resume.
video_adapter_pm.dpms_on (bool)  NoReactivate the screen with DPMS on resume.
video_adapter_pm.vbe_post (bool)  NoRun the VGA BIOS Power On Self Test (POST) on resume.
video_adapter_pm.vbestate_restore (bool)  NoSave the VGA BIOS state before suspend, and restore it on resume.
video_adapter_pm.vbemode_restore (bool)  NoSave the VGA BIOS mode before suspend, and restore it on resume.

The following methods exist on the interface org.freedesktop.Hal.Device.VideoAdapterPM.

Method (parameter types)ParametersMandatoryDescription
void SuspendVideo (void) NoneNo Suspends the video adapter using the quirks specified.
void ResumeVideo (void) NoneNo Resumes the video adapter using the quirks specified.


2.3.20. ac_adaptor namespace

Device objects with the capability ac_adaptor represent all the devices capable of powering the system from AC power

Key (type)ValuesMandatoryDescription
ac_adaptor.present (bool)  Yes The state of the adaptor, i.e. whether it is providing power to the unit from mains power.


2.3.21. battery namespace

Device objects with the capability battery represent all the devices having some battery (in many cases - rechargeable) inside.

Key (type)ValuesMandatoryDescription
battery.present (bool)  Yes This is present as some smart batteries can have acpi/pmu entries, and be physically missing.
battery.type (string)  Yes This property defines the type of the device holding the battery. This property is defined for the development simplicity - battery indicators can use it to find the proper iconic representation.
  pda   The device containing the battery is a personal digital assistant, e.g. a device that looks like a handheld computer to do specific tasks such as keeping notes or containing a personal database
  ups   A battery powered power supply that is guaranteed to provide power to a computer in the event of interruptions in the incoming electrical power. Most of the time this is an external device.
  primary   The battery is a primary power source for the system - an example are laptop batteries.
  mouse   The device containing the battery is a mouse.
  keyboard   The device containing the battery is a keyboard.
  keyboard_mouse   The device containing the battery is a combined mouse and keyboard.
  camera   The device containing the battery is a camera.
  unknown   The device containing the battery is not covered by other types.
battery.charge_level.unit (string) Examples: mWh, percent No The physical unit used by the charge level properties (maximum and current). In many cases, this property is omitted - which indicates that the charge properties are measured in some unknown units. The units should never be mAh as this is not a measurement of charge.
battery.charge_level.design (int)  Yes The maximum level of charge the device was designed for. Measured in "battery.charge_level.unit" units.
battery.charge_level.last_full (int)  Yes The maximum level of charge the device could hold the last time it was full. Measured in "battery.charge_level.unit" units.
battery.charge_level.current (int)  Yes The current level of charge which the device can is holding. Measured in "battery.charge_level.unit" units.
battery.charge_level.rate (int)  No The discharge/charge rate measured in "battery.charge_level.unit" units per second.
battery.charge_level.warning (int)  No Once the charge level of the battery drops below this value its state changes to 'warning'. Measured in "battery.charge_level.unit" units.
battery.charge_level.low (int)  No Once the charge level of the battery drops below this value its state changes to 'low'. Measured in "battery.charge_level.unit" units.
battery.charge_level.granularity_1 (int)  No Granularity value one of the battery measured in "battery.charge_level.unit" units .
battery.charge_level.granularity_2 (int)  No Granularity value two of the battery measured in "battery.charge_level.unit" units.
battery.reporting.unit (string) Examples: mWh, mAh, percent No The physical unit used by the charge level properties (maximum and current) as reported by the hardware. In many cases, this property is omitted - which indicates that the charge properties are measured in some unknown units.
battery.reporting.design (int)  Yes The maximum level of charge the device was designed for, as reported by the hardware. Measured in "battery.reporting.unit" units.
battery.reporting.last_full (int)  No The maximum level of charge the device could hold the last time it was full, as reported by the hardware. Measured in "battery.reporting.unit" units.
battery.reporting.current (int)  No The current level of charge which the device is holding, as reported by the hardware. Measured in "battery.reporting.unit" units.
battery.reporting.rate (int)  No The discharge/charge rate as reported by the hardware measured in "battery.reporting.unit" units per second.
battery.reporting.warning (int)  No Once the hardware charge level of the battery drops below this value its state changes to 'warning'. Measured in "battery.reporting.unit" units.
battery.reporting.low (int)  No Once the hardware charge level of the battery drops below this value its state changes to 'low'. Measured in "battery.reporting.unit" units.
battery.reporting.granularity_1 (int)  No Hardware granularity value one of the battery measured in "battery.reporting.unit" units .
battery.reporting.granularity_2 (int)  No Hardware granularity value two of the battery measured in "battery.reporting.unit" units.
battery.charge_level.capacity_state (string) Examples: ok, critical No The capacity state of the battery.
battery.voltage.unit (string) Examples: mV No The physical measurement unit used by the voltage properties (design and current).
battery.voltage.design (int)  Yes The voltage level for which the battery is designed for. Measured in "battery.voltage.unit" units.
battery.voltage.current (int)  Yes The voltage level currently emitted by the battery. Measured in "battery.voltage.unit" units.
battery.alarm.unit (string) Examples: mWh, mAh No The physical measurement unit used by the alarm property.
battery.alarm.design (int)  No Once the charge level of the battery drops below this value its state changes to 'alarm'. Measured in "battery.alarm.unit" units.
battery.remaining_time (int)  No Remaining time, in seconds, that the battery can provide power (if discharging) or the time until charged (if charging). This is an estimate and may be imprecise. This key is not present for invalid data.
battery.remaining_time.calculate_per_time (bool)  No If this property is true the battery.remaining_time becomes guessed from battery.charge_level.current and time.
battery.charge_level.percentage (int)  No Charge, normalised to percent. This is useful if an application does not want to process the raw values and do all the extra checks on the result. This key is not present for invalid data.
battery.is_rechargeable (bool)  No True if the battery unit is rechargeable, false if its is one-time (disposable after one usage).
battery.rechargeable.is_charging (bool)   Only if battery.is_rechargeable is TRUE TRUE if, and only if, the battery is charging.
battery.rechargeable.is_discharging (bool)   Only if battery.is_rechargeable is TRUE TRUE if, and only if, the battery is discharging.
battery.command_interface (string)  No The abstract name allowing daemons and/or user-level apps to distinguish some groups of devices having similar programming interface. Introduced mostly for the daemons' coding simplicity.
battery.vendor (string)  No Vendor of the battery.
battery.model (string)  No Make of the battery.
battery.reporting.technology (string) example: LIONNo The technology of the battery as reported by the hardware.
battery.technology (string) lead-acid, lithium-ion, lithium-polymer, nickel-metal-hydride, unknown No The technology of the battery processed to a few standard types. This key is needed as the hardware often does not specify the description text for a battery, and so we have to calculate it from the output of battery.reporting.technology.
battery.serial (string)  No A string uniquely identifying the instance of the battery; it will be different for two (otherwise) identical batteries.


2.3.22. button namespace

Device objects with the capability button represent the devices capable of providing a state to the system.

Key (type)ValuesMandatoryDescription
button.type (string)  NoThe type of button
 lid  The switch on a laptop that senses whether the lid is open or closed
 power The main power button on the computer.
 sleep  The sleep button on a computer capable of putting the computer into a suspend state
button.has_state (bool)  noTrue if the button maintains state, e.g. can toggled on/off
button.state.value (bool)   Only when button.has_state is TRUE State of the button, TRUE if it is enabled

Device objects with this capability may emit the following events.

Condition NameParametersExampleDescription
ButtonPressed button.type (string) sleepEmitted when a button is pressed


2.3.23. processor namespace

Device objects with the capability processor represent CPU's in the system.

Key (type)ValuesMandatoryDescription
processor.number (int)  Yes The internal processor number in the system, starting from zero
processor.can_throttle (bool)  No Whether the processor supports throttling to decrease it's own clock speed
processor.maximum_speed (long) example: 2200NoThe maximum speed of the processor in units of MHz


2.3.24. display_device namespace

Device objects with the capability display_device represent display devices attached to the system.

Key (type)ValuesMandatoryDescription
display_device.type (string)  YesThe type of display device
 lcd LCD panel
 crt CRT tube
 tv_out TV Out
display_device.lcd.brightness (int)   Only if display_device.type is lcd Brightness level in percent


2.3.25. sensor namespace

Device objects with the capability sensor represent light or temperature sensors in the system.

Key (type)ValuesMandatoryDescription
sensor.type (string)  YesThe type of sensor device
 light Light sensor
 temperature Temperature sensor
sensor.location (string)  YesThe location of the sensor device
 gpu Measures GPU source
 cpu Measures CPU source
 external Measures external source
 unknown Measuring other source


2.3.26. power_management namespace

Keys with the prefix power_management provide information about power management supported by your computer.

Key (type)ValuesMandatoryDescription
power_management.type (string) Examples: apm, acpi, pmu Yes The power management subsystem used on the computer.
power_management.can_suspend (bool)  Yes If suspend (S3) support is compiled into the kernel. NB. This may not mean the machine is able to suspend successfully.
power_management.can_hibernate (bool)  Yes If hibernation (S4) support is compiled into the kernel. NB. This may not mean the machine is able to hibernate successfully.
power_management.can_standby (bool)  Yes If standby (S1) support is compiled into the kernel. NB. This may not mean the machine is able to standby successfully.
power_management.can_suspend_to_ram (bool)  No If suspend (S3) support is compiled into the kernel. NB. This may not mean the machine is able to suspend successfully. WARNING: This key is depreciated and power_management.can_suspend should be used in its place. This key will be removed, but not before May 1st 2007.
power_management.can_suspend_to_disk (bool)  No If hibernation (S4) support is compiled into the kernel. NB. This may not mean the machine is able to hibernate successfully. WARNING: This key is depreciated and power_management.can_hibernate should be used in its place. This key will be removed, but not before May 1st 2007.

The following methods exist on the interface org.freedesktop.Hal.Device.SystemPowerManagement.

Method (parameter types)ParametersMandatoryDescription
Suspend (integer) The number of seconds until we resume automatically, or zero if we should not auto-resume. No This method puts the system in a state where little power is consumed. The system is not operational while in this state. Latency for the system to return to an operational state is in the order of magnitude of 5 seconds.
Hibernate (void)  No This method puts the system in a state where no power is consumed. The system is not operational while in this state. Latency for the system to return to an operational state is in the order of magnitude of one minute.

The following methods exist on the interface org.freedesktop.Hal.Device.CPUFreq.

Method (parameter types)ParametersMandatoryDescription
SetCPUFreqGovernor (string) The name of the governor to set. Get a list of available governors with the GetCPUFreqAvailableGovernors method. No Sets a CPU frequency scaling governor for all CPUFreq interfaces the kernel provides. If the userspace governor is set, this interface also contains a proper scaling mechanism. The default performance is set to 50.
SetCPUFreqPerformance (integer) The performance between 1 and 100 to set in dynamic scaling modes. No Sets the performance of the dynamic scaling mechanism. This method summarizes and abstracts all the different settings which can be taken for dynamic frequency adjustments, like at which load to switch up frequency or how many steps the mechanism should traverse until reaching the maximum frequency. The higher the value, the more performance you get. Respectively, the higher the value, the sooner and the more often the frequency is switched up.
SetCPUFreqConsiderNice (boolean) Whether or not niced processes should be considered on CPU load calculation. No Whether or not niced processes should be considered on CPU load calculation. If niced processes are considered, they can cause a frequency increment although their absolute load percentage wouldn't trigger the scaling mechanism to switch up the frequency. The default setting is 'false'.
GetCPUFreqGovernor (void)  No Get the current active governor for all CPU frequency interfaces (string).
GetCPUFreqPerformance (void)  No Get the current active performance setting if a dynamic scaling mechanism is in use (integer between 1 and 100).
GetCPUFreqConsiderNice (void)  No Returns whether niced processed are considered during CPU load calculation or not (returns boolean).
GetCPUFreqAvailableGovernors (void)  No Returns a list of strings of all available governors which could be set with the SetCPUFreqGovernor method.

The following errors maybe raised on the interface org.freedesktop.Hal.Device.CPUFreq.

ErrorDescriptionDetail field
GeneralError A general error occured. The exact error.
UnknownGovernor The governor which was tried to be set doesn't exist. The governor which was tried be to set.
PermissionDenied The caller doesn't have the privilege to execute this method. The privilege the caller needs to execute the method.
NoSuitableGovernor The method executed doesn't exist for the current active governor. The method which was tried to be executed.
GovernorInitFailed The initialization of the governor failed. The reason for the failure.


2.3.27. tape namespace

Device objects with the capability tape represent tape devices.

Key (type)ValuesMandatoryDescription
tape.major (int) example: 254YesThe device's major number
tape.minor (int) example: 0YesThe device's minor number


2.4. Policy Properties

The properties on a hal device object can be used to express certain policies about how the device is to be used. This information can be used by either programs querying hal directly or by hal callouts. Default policy (e.g. always mount a file system with the option 'exec') can also be merged on the root computer device object.


2.4.1. storage.policy.default namespace

This namespace specifies the default policy for storage devices - these properties should be merged on the root computer device object.

Key (type)ValuesMandatoryDescription
storage.policy.default.use_managed_keyword (string)  No Whether to use a managed no operation keyword when adding entries to the File Systems file (/etc/fstab) - this is used to identify entries added by a program that modifies this file.
storage.policy.default.managed_keyword.primary (string) Example: 'managed'NoNo-op keyword to use when adding entries to the file systems file
storage.policy.default.managed_keyword.secondary (string) Example: 'kudzu'No Secondary no-op keyword that identifies entries added to the file systems file. The secondary keyword is never written; only read. This is useful when making a transition from one managed keyword to another.
storage.policy.default.mount_option.* (bool) Examples: .noauto, .exec, .console, .fscontext=system_u:object_r:removable_t No This is actually an entire namespace that specifies what options a storage device should be mounted with, e.g. the example .exec should be read as storage.policy.default.mount_option.exec
storage.policy.default.mount_root (string) Example: /media No The default mount root to use when computing what mount point to use for a storage device


2.4.2. storage.policy namespace

This namespace contains properties that can be merged on individual storage devices to specify how and if the storage device should be mounted.

Key (type)ValuesMandatoryDescription
storage.policy.should_mount (bool)  NoWhether any volumes from this storage device should be mounted
storage.policy.desired_mount_point (string)   No (only applicable if the property storage.no_partitions_hint is set to TRUE) The desired mount point for this storage device. The path must not be fully qualified and there is no guarantee that and storage policy agents, such as policy mount wrappers or programs modifying the file systems file will use this mount point.
storage.policy.mount_option.* (bool)   No (only applicable if the property storage.no_partitions_hint is set to TRUE) Mount options to use, see property storage.policy.default.mount_option.* for details.
storage.policy.mount_filesystem (string)   No (only applicable if the property storage.no_partitions_hint is set to TRUE) File system to use when mounting the storage device.


2.4.3. volume.policy namespace

This namespace contains properties that can be merged on individual volumes to specify how and if the volume should be mounted.

Key (type)ValuesMandatoryDescription
volume.policy.should_mount (bool)  NoWhether this volume should be mounted at all
volume.policy.mount_filesystem (string)  NoFile system to use when mounting the volume.
volume.policy.desired_mount_point (string)  No The desired mount point for this volume. The path must not be fully qualified and there is no guarantee that and storage policy agents, such as policy mount wrappers or programs modifying the file systems file will use this mount point.
volume.policy.mount_option.* (bool)  No Mount options to use, see property storage.policy.default.mount_option.* for details.


Chapter 3. Device Information Files

Device information files (.fdi files is a shorthand) are used to merge arbitrary properties onto device objects. The way device information files works is that once all physical properties are merged onto a device object it is tried against the set of installed device information files. Device information files are used for both merging facts and policy settings about devices.

Each device information file got a number of <match key="some_property" [string|int|bool|..]="required_value" > directives that is tested against the properties of the device object. If all the match directives passes then the device information can include <[merge|append|prepend] key="some_property" type="[string|int|bool|..]"> directives to respectively merge new properties or append to existing properties on the device object. It's important to emphasize that any previously property stemming from device detection can be overridden by a device information file.

The <match>, <merge>, <append> and <prepend> directives always requires the key attribute which must be either a property name on the device object in question or a path to a property on another device object. The latter case is expressed either through direct specification of the UDI, such as /org/freedesktop/Hal/devices/computer:foo.bar or indirect references such as @info.parent:baz where the latter means that the device object specified by the UDI in the string property info.parent should be used to query the property baz. It is also possible to use multiple indirections, e.g. for a volume on a USB memory stick the indirection @block.storage_device:@storage.physical_device:usb.vendor_id will reference the usb.vendor_id property on the device object representing the USB interface.

When the property to match have been determined a number of attributes can be used within the <match> tag:

The <merge>, <append> and <prepend> directives all require the type attribute which specifies what to merge. The following values are supported

The <remove>, directive require only a key and can be used with all keys. For strlist there is additionally a special syntax to remove a item from the string list. For example to remove item 'bla' from property 'foo.bar': <remove key="foo.bar" type="strlist">bla</remove>

Device Information files are stored in the following standard hierachy with the following default top level directories information, policy and preprobe:

All device information files are matched for every hal device object.


3.1. Facts about devices

3.1.1. Example: MP3 player

        <?xml version="1.0" encoding="UTF-8"?>

<!-- Example: This device information file matches an USB Mass Storage based MP3 player 
              by the matching on the USB vendor and product identifiers. -->

<deviceinfo version="0.2">
  <device>
    <match key="info.bus" string="usb">
      <match key="usb.vendor_id" int="0x066f">
        <match key="usb.product_id" int="0x8000">
          <merge key="info.category" type="string">portable_audio_player</merge>
          <merge key="info.capabilities" type="string">portable_audio_player</merge>
          <merge key="portable_audio_player.access_method" type="string">storage</merge>
          <merge key="portable_audio_player.output_formats" type="string">audio/mpeg audio/x-ms-wma</merge>
          <merge key="portable_audio_player.input_formats" type="string">audio/x-wav</merge>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>
      

The final set of properties look like this:


3.1.2. Example: Digital Still Camera

        <?xml version="1.0" encoding="UTF-8"?>

<!-- Example: This device information file matches a Sony digital still 
              camera by matching on the USB vendor and product identifers.  -->

<deviceinfo version="0.2">
  <device>
    <match key="info.bus" string="usb">
      <match key="usb.vendor_id" int="0x054c">
        <match key="usb.product_id" int="0x0010">
          <merge key="info.category" type="string">camera</merge>
          <merge key="info.capabilities" type="string">camera</merge>
          <merge key="camera.access_method" type="string">storage</merge>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>
      

The final set of properties look like this:


3.1.3. Example: Card Reader

        <?xml version="1.0" encoding="UTF-8"?>

<!-- Example: This device information file matches a memory card reader with 
              multiple storage ports that can be active at the same time. -->

<deviceinfo version="0.2">
  <device>
    <match key="storage.bus" string="usb">
      <match key="@storage.physical_device:usb.vendor_id" int="0x0424">
        <match key="@storage.physical_device:usb.product_id" int="0x20fc">
          <match key="storage.lun" int="0">
            <merge key="storage.drive_type" type="string">compact_flash</merge>
	  </match>
          <match key="storage.lun" int="1">
            <merge key="storage.drive_type" type="string">memory_stick</merge>
	  </match>
          <match key="storage.lun" int="2">
            <merge key="storage.drive_type" type="string">smart_media</merge>
	  </match>
          <match key="storage.lun" int="3">
            <merge key="storage.drive_type" type="string">sd_mmc</merge>
	  </match>
        </match>
      </match>
    </match>
  </device>
</deviceinfo>
      

As described in the documentation for the storage.physical_device property in Section 2.3.4 this device information file export information about each storage port through the property storage.drive_type. Thus, one of the four storage devices has the following properties that are merged from the device object that the device information file targets:


3.2. Policy settings for devices

Policy settings specifies system specific settings that a system administrator associates with a device instance. In the context of hal, this can be expressed in terms of device properties merged on the device object in question. Default policy can also be merged on the root computer device object.


3.2.1. Storage Devices

Policy for storage devices is expressed in the storage.policy.default, storage.policy and volume.policy namespaces, see Section 2.4 for details.

        <?xml version="1.0" encoding="UTF-8"?>

<deviceinfo version="0.2">

  <!-- Example: Match volumes from an external USB harddisk enclosure by 
                matching on vendor and model. Use mount points 

  		    my_usbdisk_part_<partition-number>

		NB: some drives (ieee1394 based IIRC) even export the
		property storage.serial, the unique serial number of the
		disk which is a better match -->
  <device>
    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
	<match key="@block.storage_device:storage.vendor" string="ST360021">
	  <match key="@block.storage_device:storage.model" string="A">
	    <merge key="volume.policy.desired_mount_point" type="string">my_usbdisk_partition_</merge>
	    <append key="volume.policy.desired_mount_point" type="copy_property">volume.partition.number</append>
	  </match>
	</match>
      </match>
    </match>
  </device>

  <!-- Example: Match a volume from an USB Storage Based mp3 player
                by the file system UUID and assign a mount point.

                NB: When reformatting the volume a new UUID will be
                used and this rule will have to be altered -->
  <device>
    <match key="block.is_volume" bool="true">
      <match key="volume.fsusage" string="filesystem">
	<match key="volume.uuid" string="4150-3F34">
	  <merge key="volume.policy.desired_mount_point" type="string">my_mp3_player</merge>
	</match>
      </match>
    </match>
  </device>

</deviceinfo>
      

Chapter 4. Examples and other stuff

4.1. Callouts

Callouts are programs invoked when the device object list is modified. As such, callouts can be used to maintain system-wide policy (that may be specific to the particular OS) such as changing permissions on device nodes, updating the systemwide /etc/fstab file or configuring the networking subsystem.

There are three different classes of callouts. A callout involves sequentially invoking all executable programs in the string list in listed order.

Key (type)ValuesMandatoryDescription
info.callouts.add (string list)  No A string list with all programmes/callouts which should be executed (with HALD_ACTION=add) when the device is added to the GDL (global device list) but just before it is announced through the D-BUS network API.
info.callouts.remove (string list)  No A string list with all programmes/callouts which should be executed (with HALD_ACTION=remove) when the device is removed from the GDL (global device list). The device isn't removed before the last callout has finished.
info.callouts.preprobe (string list)  No A string list with all programmes/callouts which should be executed (with HALD_ACTION=preprobe) before the device is added to the GDL (global device list) and before the callouts from info.callouts.add are executed.

All callouts execute in the same environment as which the HAL daemon was started. In addition, the UDI of the device object is exported in the environment variable UDI. All properties of the device object are exported in the environment prefixed with HAL_. If a device is added or removed is exported in the environment variable HALD_ACTION ,if HAL is in shutdown mode the variable HALD_SHUTDOWN is set to environment.

The HAL daemon isn't suspended while callouts are executing. Thus, callouts can communicate with the HAL daemon using the D-BUS network API. Hence, one application of callouts is to merge or modify properties on a device object.


4.2. D-BUS Network API

The HAL daemon is a system-wide process that keeps track of a number of device objects. It communicates with the operating system and intercepts hotplug events as devices are plugged in and removed. The daemon is also responsible for providing services to applications that wants to locate devices and perform generic operations on them such as obtaining exclusive access. Non-generic operations, such as obtaining pictures from a camera device, is outside the scope of the HAL daemon; see Section 1.7 for more information.

HAL has the concept of device stores. When a device is detected it is placed in the TDL (temporary device list) and then properties are merged from several sources including device information files and possibly callouts. Eventually, the device transitions to the GDL (global device list) and first then it becomes ''visible'' for desktop applications.


4.2.1. Interface org.freedesktop.Hal.Manager

Using D-BUS terminology, the HAL daemon provides the D-BUS service org.freedesktop.Hal. This service offers a D-BUS object at a well-known location /org/freedesktop/Hal/Manager. This object offers a D-BUS interface, org.freedesktop.Hal.Manager, for querying device objects with the following methods:

# Return a list of all devices in the GDL
#
# @return                       List of UDI's
#
array{string} GetAllDevices()
# Determine if a device with a given Unique Device Id exists in the GDL
#
# @param  udi                   Device UDI, for example '/org/freedesktop/Hal/devices/pci_8086_7111'
# @return                       TRUE iff the device with the given UDI exists
#
bool DeviceExists(string udi)
# Find the set of devices in the GDL that has a given property matching
# a given value
#
# @param  key                   Key, for example 'block.fstype'
# @param  value                 Value, for example 'ext3'
# @return                       Array of UDI's, may be empty
#
array{string} FindDeviceStringMatch(string key, string value)
# Find the set of devices in the GDL that has a given capability
#
# @param  capability            Capability, for example 'volume'
# @return                       Array of UDI's, may be empty
#
array{string} FindDeviceByCapability(string capability)
      

This object also emits the following signals on the /org/freedesktop/Hal/Manager object on the org.freedesktop.Hal.Manager interface that applications can subscribe to using D-BUS:

# Notification that a new device have been added to the GDL
#
# @param  udi                   Unique Device Id
#
void DeviceAdded(string udi)
# Notification that a new device have been removed from the GDL. The
# application cannot use this UDI anymore.
#
# @param  udi                   Unique Device Id
#
void DeviceRemoved(string udi)
# Notification that a device in the GDL have got a new capability. Note that
# this is emitted even though the device already had the old capability
#
# @param  udi                   Unique Device Id
#
void NewCapability(string udi, string capability)
      

4.2.1.1. Example

The following brief Python program demonstrates some of the API

          #!/usr/bin/python
 
import gtk
import dbus

def device_added(interface, signal_name, service, path, message):
    [udi] = message.get_args_list ()
    print 'Device %s was added'%udi

def device_removed(interface, signal_name, service, path, message):
    [udi] = message.get_args_list ()
    print 'Device %s was removed'%udi

 
bus = dbus.Bus (dbus.Bus.TYPE_SYSTEM)
hal_service = bus.get_service ('org.freedesktop.Hal')
hal_manager = hal_service.get_object ('/org/freedesktop/Hal/Manager',
				      'org.freedesktop.Hal.Manager')

devices = hal_manager.GetAllDevices ()
for d in devices:
    print 'Found device %s'%d

bus.add_signal_receiver (device_added,
			 'DeviceAdded',
			 'org.freedesktop.Hal.Manager',
			 'org.freedesktop.Hal',
			 '/org/freedesktop/Hal/Manager')
bus.add_signal_receiver (device_removed,
			 'DeviceRemoved',
			 'org.freedesktop.Hal.Manager',
			 'org.freedesktop.Hal',
			 '/org/freedesktop/Hal/Manager')
gtk.main()
        

which gives the following output

Found device /org/freedesktop/Hal/devices/block_TORiSAN DVD-ROM DRD-U624-00000000000000000001-disc
Found device /org/freedesktop/Hal/devices/block_TORiSAN DVD-ROM DRD-U624-00000000000000000001
Found device /org/freedesktop/Hal/devices/block_37332a77-105e-4e76-8e99-27d3746e0531
Found device /org/freedesktop/Hal/devices/block_3_2
Found device /org/freedesktop/Hal/devices/block_LS-120 SLIM3 00 UHD Floppy-0208MBA00211
Found device /org/freedesktop/Hal/devices/block_IC25N020ATCS05-0-CLP225F2G3UR4A
Found device /org/freedesktop/Hal/devices/ide_1_1
Found device /org/freedesktop/Hal/devices/ide_0_0
Found device /org/freedesktop/Hal/devices/ide_1_0
Found device /org/freedesktop/Hal/devices/usbif_usb_0_0_206_-1_0000:00:07.2_0
Found device /org/freedesktop/Hal/devices/ide_host_0
Found device /org/freedesktop/Hal/devices/ide_host_1
Found device /org/freedesktop/Hal/devices/pci_104c_8400
Found device /org/freedesktop/Hal/devices/usb_0_0_206_-1_0000:00:07.2
Found device /org/freedesktop/Hal/devices/pci_1002_4c4d
Found device /org/freedesktop/Hal/devices/pci_125d_1978
Found device /org/freedesktop/Hal/devices/pci_8086_7111
Found device /org/freedesktop/Hal/devices/pci_104c_ac1c/0
Found device /org/freedesktop/Hal/devices/pci_8086_7112
Found device /org/freedesktop/Hal/devices/pci_8086_7110
Found device /org/freedesktop/Hal/devices/input_13_65
Found device /org/freedesktop/Hal/devices/pci_104c_ac1c
Found device /org/freedesktop/Hal/devices/pci_8086_7190
Found device /org/freedesktop/Hal/devices/input_13_64
Found device /org/freedesktop/Hal/devices/pci_8086_7113
Found device /org/freedesktop/Hal/devices/pci_8086_7191
Found device /org/freedesktop/Hal/devices/computer
(insert USB mouse)
Device /org/freedesktop/Hal/devices/usb_46d_c001_410_-1_noserial was added
Device /org/freedesktop/Hal/devices/usbif_usb_46d_c001_410_-1_noserial_0 was added
(remove USB mouse)
Device /org/freedesktop/Hal/devices/usb_46d_c001_410_-1_noserial was removed
Device /org/freedesktop/Hal/devices/usbif_usb_46d_c001_410_-1_noserial_0 was removed
        


4.2.2. Interface org.freedesktop.Hal.Device

Applications use the org.freedesktop.Hal.Manager interface to locate the device objects they are interested in. When a device object (which is really a D-BUS object, note that the UDI is the objects object_path) is obtained, the HAL daemon provides the org.freedesktop.Hal.Device interface on the object denoted by the UDI. This interface has the following methods

# Set property
#
# @param  key                   Property to set
# @param  value                 Value to set
# @raises                       org.freedesktop.Hal.(NoSuchDevice|TypeMismatch|PermissionDenied)
#
void SetProperty(string key, any value)
void SetPropertyString(string key, string value)
void SetPropertyInteger(string key, int32 value)
void SetPropertyBoolean(string key, bool value)
void SetPropertyDouble(string key, double value)
# Get property
#
# @param  key                   Property to get
# @return                       The value of the property
# @raises                       org.freedesktop.Hal.(NoSuchDevice|NoSuchProperty|TypeMismatch)
#
any GetProperty(string key)
string GetPropertyString(string key)
int32 GetPropertyInteger(string key)
bool GetPropertyBoolean(string key)
double GetPropertyDouble(string key)
# Get all properties
#
# @return                       Dictionary from key to value
# @raises                       org.freedesktop.Hal.NoSuchDevice
#
map{string, any} GetAllProperties()
# Remove a property
#
# @param  key                   Property to remove
# @raises                       org.freedesktop.Hal.(NoSuchDevice|NoSuchProperty|PermissionDenied)
#
void RemoveProperty(string key)
# Get the type of a property
#
# @param  key                   Property
# @return                       D-BUS type of property
# @raises                       org.freedesktop.Hal.(NoSuchDevice|NoSuchProperty)
#
int32 GetPropertyType(string key)
# Determine if a property exists
#
# @param  key                   Property
# @return                       TRUE iff the property exists
# @raises                       org.freedesktop.Hal.NoSuchDevice
#
bool PropertyExists(string key)
# Add a capability to a device. Note that this will trigger a NewCapability
# signal to all client applications subscribing to signals from the Manager
# interface.
#
# @param  capability            Capability, e.g. 'net.80211'
# @raises                       org.freedesktop.Hal.(NoSuchDevice|PermissionDenied)
#
void AddCapability(string capability)
# Determine if a device got a given capability
#
# @param  capability            Capability, e.g. 'storage.cdrom'
# @return                       TRUE iff the device got the given capability
# @raises                       org.freedesktop.Hal.NoSuchDevice
#
bool QueryCapability(string capability)
# Take an advisory lock on the device.
#
# @param  reason                A user-presentable reason why the device
#                               is locked.
# @raises                       org.freedesktop.Hal.NoSuchDevice,
#                               org.freedesktop.Hal.DeviceAlreadyLocked
#
void Lock(string reason)
# Release an advisory lock on the device.
#
# @raises                       org.freedesktop.Hal.NoSuchDevice,
#                               org.freedesktop.Hal.DeviceAlreadyLocked,
#                               org.freedesktop.Hal.PermissionDenied
#
void Unlock()
      

The device objects also emits the following signals on the org.freedesktop.Hal interface that applications can subscribe to using D-BUS

# Notification that property have been modified
#
# @param  key                   Property
# @param  added                 True iff the property have been added
# @param  removed               True iff the property have been removed
#
void PropertyModified(string key, bool added, bool removed)
# Notification that an event happened on the device has occured.
#
# Normally this is used to signal events that aren't or can't be expressed
# in properties, e.g. 'ProcessorOverheating' etc.
#
# @param  condition             Name of condition
# @param  ...                   Dependent on the condition name
void Condition(string condition, ...)
      

Note that D-BUS supports that applications can opt to receive signals for only a subset of the devices available.


4.2.3. Interface org.freedesktop.Hal.Device.Volume

The org.freedesktop.Hal.Device.Volume interface is used on objects with the "volume" capability. This interface has the following methods.

# Mount volume
#
# @param  mountpoint            Desired mount point. If NULL, will be generated based on label.
# @param  fstype                Filesystem type
# @param  options               Mount options
# @raises                       org.freedesktop.Hal.Device.Volume.NoSuchDevice
#                               org.freedesktop.Hal.Device.Volume.PermissionDenied
#                               org.freedesktop.Hal.Device.Volume.AlreadyMounted
#                               org.freedesktop.Hal.Device.Volume.InvalidMountOption
#                               org.freedesktop.Hal.Device.Volume.UnknownFilesystemType
#                               org.freedesktop.Hal.Device.Volume.InvalidMountpoint
#                               org.freedesktop.Hal.Device.Volume.MountPointNotAvailable
#                               org.freedesktop.Hal.Device.Volume.PermissionDeniedByPolicy
#
void Mount(string mountpoint, string fstype, array{string} options)
# Unmount volume
#
# @param  options               Unmount options
# @raises                       org.freedesktop.Hal.Device.Volume.NoSuchDevice
#                               org.freedesktop.Hal.Device.Volume.PermissionDenied
#                               org.freedesktop.Hal.Device.Volume.InvalidUnmountOption
#                               org.freedesktop.Hal.Device.Volume.InvalidMountpoint
#                               org.freedesktop.Hal.Device.Volume.MountPointNotAvailable
#                               org.freedesktop.Hal.Device.Volume.PermissionDeniedByPolicy
#
void Unmount(array{string} options)
# Eject volume
#
# @param  ejectoptions          Eject options
# @raises                       org.freedesktop.Hal.Device.Volume.NoSuchDevice
#                               org.freedesktop.Hal.Device.Volume.PermissionDenied
#                               org.freedesktop.Hal.Device.Volume.InvalidEjectOption
#                               org.freedesktop.Hal.Device.Volume.PermissionDeniedByPolicy
#
void Eject(array{string} options)
      

4.2.4. Interface org.freedesktop.Hal.Device.Storage

The org.freedesktop.Hal.Device.Storage interface is used on objects with the "storage" capability. This interface has the following methods.

# Eject media
#
# @param  ejectoptions          Eject options
# @raises                       org.freedesktop.Hal.Device.Storage.NoSuchDevice
#                               org.freedesktop.Hal.Device.Storage.PermissionDenied
#                               org.freedesktop.Hal.Device.Storage.InvalidEjectOption
#                               org.freedesktop.Hal.Device.Storage.PermissionDeniedByPolicy
#
void Eject(array{string} options)
# Close media tray
#
# @param  closetrayoptions      Close tray options
# @raises                       org.freedesktop.Hal.Device.Storage.NoSuchDevice
#                               org.freedesktop.Hal.Device.Storage.PermissionDenied
#                               org.freedesktop.Hal.Device.Storage.InvalidCloseTrayOption
#                               org.freedesktop.Hal.Device.Storage.PermissionDeniedByPolicy
#
void CloseTray(array{string} options)
      

4.3. Enforcing Policy

Notwithstanding the fact that HAL avoids to enforce any policy, it is useful to have a minimal set of guidelines such that applications using HAL written for one operating system can easily run on another. This section contains recommendations about how to enforce policy to achieve that goal.


4.3.1. Storage Devices

4.3.1.1. Policy for Volumes and Storage devices

The properties in the storage.policy, volume.policy and storage.policy.default namespaces should be the preferred way to determine how and if a filesystem can be mounted. See Section 2.4 for details.


4.3.1.2. File systems file

An operating system vendor should maintain the /etc/fstab file through the HAL callout mechanism such that device objects of capability volume and storage has a corresponding entry if applicable cf. Section 4.3.1.1 .

The reasoning behind this is, among other things, to maintain the invariant that /etc/fstab list all available filesystems. In addition the mount(1) program should enable users without superuser privileges to mount filesystems mentioned in the /etc/fstab file as long as they have the user option set.


4.3.1.3. Disabling policy agents

Policy agents like volume mounters should ignore when media is inserted into a drive that is locked by another application. Thus, CD burning applications should lock the device to disable auto mounting or automatic start of the users preferred CD burning application when respectively non-blank rewritable or blank media is inserted.