1. D-BUS overview
2. HAL overview
2.1 Basic terminology
2.2 External programs
2.3 Customization via .fdi files
2.3.1 File format
2.3.2 File hierarchy
2.3.3 Examples
2.4 PolicyKit
2.5 HAL D-BUS API
2.5.1 Interface org.freedesktop.Hal.Manager
2.5.2 Interface org.freedesktop.Hal.Device
======================================================================
1. D-BUS overview
D-BUS is a simple IPC (interprocess communication) protocol that allows
asynchronous messages be either directly sent between two applications
(peer to peer model) or be routed among multiple applications through
the dbus-daemon process (hub model). D-BUS is socket-based and can
operate both through local sockets and TCP/IP.
Each application using D-BUS contains objects. Object pointer is an
ascii string called an object path. Each object supports one or more
interfaces. There are four types of D-BUS messages:
- Method call messages ask to invoke a method on an object.
- Method return messages return the results of invoking a method.
- Error messages return an exception caused by invoking a method.
- Signal messages are notifications that a given signal has been
emitted (that an event has occurred).
All D-BUS functionality is encapsulated in libdbus.so, however the
library is almost never used directly. Instead, applications use one of
the wrapper libraries/bindings: Glib, Qt, Python, Perl, Java, Mono.
There are two modes in which dbus-daemon can run: system and session:
a. System daemon is intended for secure communication between the system
and desktop applications. It listens on a well-known socket,
/var/run/dbus/system_bus_socket by default. System daemon supports
several authentication methods.
b. Session daemon is intended for communication between desktop
applications. Under X, it is started from xinit scripts and exits with
session. The startup script not only starts the daemon, but also sets
DBUS_SESSION_BUS_ADDRESS environment variable which contains the path to
this daemon's socket.
D-BUS configuration is located in /etc/dbus directory and consists of
several XML files for session and system deamons.
More information can be found in the tutorial and the ARC case:
http://dbus.freedesktop.org/doc/dbus-tutorial.html
LSARC/2006/368 D-BUS Message Bus System
======================================================================
2. HAL overview
2.1 Basic terminology
HAL provides a view of the various hardware attached to a system,
updated dynamically as hardware configuration changes, via hotplug or
other mechanisms. HAL represents a piece of hardware as a device object.
A device object is identified by a unique identifer (UDI) and carries a
set of key/value pairs referred to as device properties. Some properties
are derived from the actual hardware, some are merged from device
information files (.fdi files) and some are related to the actual device
configuration.
HAL can collect and consolidate information from various sources: kernel
device repository, smbios, ACPI, kstats, probing. The front-end code is
OS-neutral, the back-end is OS-specific.
Applications talk to HAL through the system D-BUS, so any of the various
D-BUS bindings can be used. There is also a C library libhal.so, used,
for instance, by gnome-volume-manager.
HAL exports two D-BUS interfaces:
- "org.freedesktop.Hal.Manager", with methods to locate devices:
array{string} GetAllDevices()
bool DeviceExists(string udi)
array{string} FindDeviceStringMatch(string key, string value)
array{string} FindDeviceByCapability(string capability)
as well as signals:
void DeviceAdded(string udi)
void DeviceRemoved(string udi)
void NewCapability(string udi, string capability)
- "org.freedesktop.Hal.Device", with individual device object methods:
setting, getting and finding properties;
querying and adding capabilities;
locking/unlocking devices for exclusive use;
as well as signals:
void PropertyModified(string key, bool added, bool removed)
void Condition(string condition, ...)
Device properties are divided into namespaces, with the dot (.) as
separator. Properties are part of HAL spec. Some namespace and property
examples:
info.{bus,udi,persistent,capabilities,product,vendor,parent,locked}
usb_device.{device_class,speed_bcd,serial,product,vendor}
scsi.{host,bus,target,lun}
block.{device,major,minor,is_volume,no_partitions}
volume.{is_mounted,fstype,label,uuid,block_size,size,is_partition}
storage.{drive_type,removable,hotpluggable,requires_eject}
storage.cdrom.{cdr,cdrw,dvd,dvdr,read_speed,write_speed}
storage.policy.default.{mount_option,mount_root}
Current HAL version is 0.5.7. This means the interfaces are not stable,
however we consider this a good thing, as Sun has a chance to influence
HAL development before it reaches 1.0.
For even more HAL details:
Home page: http://www.freedesktop.org/Software/hal
HAL spec: http://tinyurl.com/kax7s
2.2 External programs
The HAL daemon process forks separate processes to perform device
probing and other tasks with potentially unpredictable behavior (such as
getting stuck in the kernel). All necessary information, such as device
UDI and event type, is passed via environment variables. The forked
process then connects to HAL via D-BUS. There are three types of
external programs: probes, addons and callouts.
- Probes are special programs used to probe a device and fill out its
properties. A probe usually opens the device and issues OS-specific
ioctls to collect information about the device. For example,
'probe-volume' determines properties such as filesystem type and size
and CD contents (audio, data, blank).
- Addons are used primarily on devices that require constant attention.
For example, 'hal-addon-storage' polls RM devices for media changes and
triggers device probe when media is inserted. So a user will see one
'hal-addon-process' process per CD/DVD drive in his system.
- Callouts are programs that are invoked when:
- devices are added/removed from GDL;
- device capabilities are added/removed;
- properties are added/removed/modified;
Callouts are located in /etc/hal/{device,capability,property}.d
directories in Linux. In Solaris, we intend not to keep any executables
in /etc, but move them to /usr/lib/hal. The initial Solaris HAL
implementaion will not include any callouts (none needed).
All external programs are managed by the hald-runner process:
hald
hald-runner
hald-addon-storage
hald-probe-volume
...
2.3 Customization via .fdi files
2.3.1 File format
XML-based device information files, or .fdi files, are used to merge
arbitrary properties onto device objects. 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.
An .fdi file contains s series of match-action directives of the form:
<match key="property" [string|int|bool|exists|empty|..]="value">
...
<[merge|append] key="property" type="[string|int|bool|..]">
...
I.e. first you match a device by one or more keys, then merge or append
a property. Any property stemming from device detection can be
overridden by an .fdi file.
The DTD for .fdi file format is included with the HAL source. The
project team proposes to deliver fdi.dtd in /usr/share/lib/xml/dtd/ and
document in the fdi(4) man page similarly to service_bundle(4). This
case also delivers the hal-fdi-validate(1M) command that validates one
or more fdi files against DTD.
2.3.2 File hierarchy
There are three classes of .fdi files:
- Preprobe: Processed before a device has been probed. Used to handle
exceptional conditions such as telling HAL to ignore a device or a
branch, run programs to upload firmware or configure the device in an
otherwise non-standard way that is incompatible with probing routines in
HAL.
- Information: Processed after a device has been probed. Describe
hardware such as what kind of media a card reader uses (CompactFlash,
MemoryStick, etc), whether the device is a camera and not just a hard
drive.
- Policy: Processed the last. Describe policy for hardware such as what
callouts and addons to run for a device.
Each class is divided into files supplied by HAL, OS vendor, OEM/3rd
party, and by local admin/user. Current HAL version creates the
following directory hierarchy:
/usr/share/hal/fdi/
preprobe
10osvendor
20thirdparty
30user
information
10freedesktop
20thirdparty
30user
policy
10osvendor
20thirdparty
30user
2.3.3 Examples
a. This file makes sure no fixed storage device gets tagged as mountable
except if it's a floppy or optical drive:
<?xml version="1.0" encoding="ISO-8859-1"?> <!-- -*- SGML -*- -->
<deviceinfo version="0.2">
<device>
<match key="storage.hotpluggable" bool="false">
<merge key="storage.policy.should_mount" type="bool">false</merge>
<match key="storage.drive_type" string="floppy">
<merge key="storage.policy.should_mount" type="bool">true</merge>
</match>
<match key="storage.drive_type" string="cdrom">
<merge key="storage.policy.should_mount" type="bool">true</merge>
</match>
</match>
</device>
</deviceinfo>
b. Many digital cameras present itself as USB mass storage devices. This
example tells HAL that this is actually a Sony camera:
<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>
2.4 PolicyKit
PolicyKit is a very recent addition to HAL (after Tamarack inception).
It is a mechanism to specify access to certain HAL features per user or
per group. For example, one could deny certain users to mount removable
disks.
The policy files are stored in plain text, although the API, libpolkit,
does not depend on it: policy store can be switched transparently to
the interface consumers.
Here's an example of a PolicyKit privilege file,
hal-storage-removable-mount.privilege:
# This privilege specifies what users can mount volumes from removable
# or hotpluggable drives using only the mount options as specified by
# the property volume.mount.valid_options on the volume in
# question. If mount options besides these are needed, one will need
# the privilege hal-removable-fixed-mount-all-options.privilege.
[Privilege]
RequiredPrivileges=desktop-console
SufficientPrivileges=
Allow=uid:__all__
Deny=
CanObtain=True
CanGrant=True
ObtainRequireRoot=False
Allow and Deny can be used to whitelist and blacklist users or groups.
As already mentioned, the mechanism is still in active development, so
not all fields are used or completely defined.
These are static PolicyKit privileges. An extension to this is also
being developed, a daemon called 'polkitd', which allows to obtain
temporary privileges, e.g. those that last for the duration of a
session or predefined time. We propose not to integrate the daemon
until it stabilizes and proves architectually fit for Solaris.
| Solaris will provide a compatible PolicyKit implementation based on
| RBAC authorizations. Each PolicyKit "privilege" would be mapped to
| a Solaris authorization, e.g. the "hal-storage-removable-mount" policy
| will be stored as a "solaris.device.mount.removable" authorization.
| This makes HAL privileges scale over NIS/LDAP and have other advantages.
2.5 HAL D-BUS API
Applications interface with HAL using D-BUS. Any D-BUS binding can be
used (glib, Python, Java). There is also a HAL-specific C API: libhal
and libhal-storage. Following defines HAL's D-BUS API:
2.5.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
# @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)
2.5.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, ...)
这边有几篇文章，值得看一下
hal_and_dbus.pdf
http://blogimg.chinaunix.net/blog/upfile2/090723115515.pdf
hal_re.pdf
http://blogimg.chinaunix.net/blog/upfile2/090723115128.pdf
hal_spec.pdf
http://blogimg.chinaunix.net/blog/upfile2/090723115540.pdf