Understanding and using Linux's hardware abstraction layer HAL __linux

Understand and use Linux the hardware abstraction layer HAL

Author: Liu Xuhui Raymond Reprint please indicate the source

Email:colorant@163.com

blog:http://blog.csdn.net/colorant/

Home: http://rgbbones.googlepages.com/

Ashamed to say that, based on the arm of the platform for such a long time, has been busy in the kernel, very little understanding of the development of the application-related, and did not contact the HAL and Dbus. Because the top of the recent project is based on the X86 software framework to do, and the previous pattern also has a big change, take this opportunity to also want to understand the upper application and the bottom-driven coordination and the previous difference, so it is natural to know HAL. Make a note of your learning comprehension.

My ability and testing time is limited, may be below some understanding, analysis is not necessarily accurate, welcome to contact.

1 Related Notes

1.1 Website Resources

Hal's official web site: Http://www.freedesktop.org/wiki/Software/hal

Http://opensolaris.org/os/project/tamarack/hal_re.html an article on the HAL Framework principle written by comrades on the Solaris system. Well, the version is a little bit old.

Http://people.freedesktop.org/~david/talks/dynamic-device-handling-OLS-2006.pdf 2006 Linux Symposium, Hal's author David Zeuthen submitted by the paper.

Incidentally, the website of the seminar is: http://www.linuxsymposium.org/There are a lot of paper look really very good ah, very interested. There are so many paper in this year's meeting that I can't wait to see it.

1.2 Working Environment

The HAL itself requirements for the environment are:

Linux kernel 2.6.17 (or later)

Util-linux 2.12r (or later)

Udev 089 (or later)

Dbus 0.61 (or later)

GLib 2.6.0 (or later)

I think the key is the kernel, below this version of the kernel will not play 8 as for my environment:

Ø Hardware Platform: Embedded board based on arm

Ø Software Environment: Linux 2.6.21, self-made file system

Ødbus 1.0.2

Øhal 0.5.10

2 Understanding Hal

2.1 What's a HAL?

To tell the truth, this part of a lot of people wrote, but for the completeness of the article, I still from the focus of my understanding to write again.

First of all, HAL is not the supercomputer in the 2001 Space Roaming series 8. The HAL is the initials of the hardware abstraction layer, the hardware abstraction layer, and the following block diagram from Hal Spec is a good illustration of its components:

It is a service program that sits on top of the operating system and driver and runs in user space.

It is designed to provide a unified and simple interface for querying hardware devices for upper-level applications. Its so-called abstraction, which is basically limited to this function, usually does not provide the actual operation of the hardware, the operation of the hardware, or the application to complete.

Refinement, in addition to providing a standard hardware query interface, it does not even consider how to configure the hardware, this is not what it will do, but it does provide storage hardware configuration related information space. Here's what we'll say, which is called attributes.

So, to put it simply, you can think of HAL as a bunch of hardware lists and a collection of their related attributes.

So, what's the use of this stack of hardware lists? It should be said that it simplifies the application of the query logic, this part of the complexity is transferred outside the application, the HAL Unified processing, and secondly, according to the author's expectation, when some library functions also began to use the HAL, the application can even put the complexity of the actual operation of different hardware to the library function to automatically process.

composition framework of 2.2 HAL

According to the above block diagram, first is the HAL Daemon,hal service process. Next is the hardware information file, the suffix FDI, and then the callout and addons, which are some of the executables or scripts required by the HAL to do additional processing for different hardware.

Inside the HAL, each hardware (concrete or abstract) is represented by a device object device.

Each device object will include components of the following concepts:

Udi:unique Device identifer A unique identifier for each device object, which is based on bus information, and its goal is to ensure the uniqueness of the device while maintaining the same value in a removable device that can be inserted multiple times during the pull out process.

Property: Attribute, is a key/value pair. Each property consists of a key and a key value that is used to store the various information related to the device object.

Method: Methods are used to read settings properties, or to provide specific actions.

Interface: This is more of a dbus concept. Properties and methods are categorized into different interface. 2.3 The source of the HAL hardware information

The main sources of information related to device objects in the HAL are as follows:

Ø obtained through SYSFS, there are quite a number of properties are obtained in this way, such as UDI, the manufacturer of the device, the parent of the device, the bus type of the device, the UUID of the hard drive, and so on.

Ø through the probe detection, some devices, such as a camera device, it supports which data format AH and so on information, the application layer program is also meaningful, but only through the Sysfs interface is not available, and through the Linux V4L2 subsystem defined by some of the standard interface functions, This information can be obtained through IOCTL. Usually this is called by the HAL service process to the corresponding callout to probe. Similarly, many subsystems define their own standard interface functions, which provides the possibility for the HAL to obtain further device information. Times, the current state of the device, such as information, may also be obtained by addon through some interfaces.

Ø through FDI equipment information file. There is also some information, possibly some generic device information (e.g.. For example), or through the detection of the hardware itself can not be obtained information, such as the definition of some special function keys on some keyboards, and so on, there may be some control information, such as the information can be added through the FDI file to the HAL's device object information data.

2.4 Hal's related files

The first is the hardware information file FDI path will be:

/USR/SHARE/HAL/FDI is usually a file provided by the System program installation package.

/ETC/HAL/FDI here is the location where the user or admin modifies FDI.

Under these two paths, there are 3 information policy preprobe and so on, which can be used to store FDI documents for different purposes. Explain later.

followed by some callout and addon of Hal, located under/usr/lib/hal/scripts and/usr/lib/hal/

There are some configuration files related to the HAL itself, and so on:

/etc/init.d/hal Hal's startup script

Rules for/etc/udev/rules.d/95-hal.rules HAL in Udev

/etc/dbus-1/system.d/hal.conf Hal's Common Interface permissions settings in Dbus.

Related Programs

/usr/bin/lshal

/usr/bin/hal-device

/usr/bin/hal-get-property

/usr/bin/hal-set-property

/usr/bin/hal-find-by-capability

/usr/bin/hal-find-by-property

/usr/bin/hal-disable-polling

/usr/bin/hal-is-caller-locked-out

/usr/bin/hal-lock

/usr/sbin

/usr/sbin/hald

2.5 HAL's device detection process