Hardware Management and Linux

The Linux Kernel manages all hardware through device drivers. Furthermore, the kernel operates in its own protected memory space, which is not accessible from user memory space. Hardware device communicate to the Kernel via interrupts and exceptions. User applications communicate to the Kernel via system calls, which actually trigger a CPU exception that interrupts the Kernel. The question becomes, how can we access what the Kernel knows about the hardware from a user space application? What user applications allow us to view this information?Some operating systems just add more system calls, Linux does not. Instead, Linux takes advantage of the Virtual File System, which is an abstract file system that standardizes the interface to all file systems. While VFS started out to be a solution to not having to modify the Kernel for every new file system, it has additional uses. For this discussion, we are going to look at two pseudo file systems: procfs and sysfs. Instead of reading and writing data to some physical media, these file systems allow us to read and write to Kernel data structures. Thus, we are viewing live Kernel data. Typically, the Kernel mounts procfs as /proc, and sysfs as /sys. We can then use the ls, cd, and pwd commands to navigate these pseudo file systems. Just remember, these commands issue standard system calls, the VFS handles the issue of which functions support these system calls.

We don’t need to know the Kernel code that makes this work, we only need to know that procfs and sysfs are reflections of current Kernel data structures. The procfs file system is the older of the two. Under procfs, file names are actually pointers to functions that access specific Kernel data structures. The sysfs file system represents the objected oriented device model that began with version 2.6 of the Kernel. Under this approach, objects are directories and files are attributes with associated getter and setter methods. To access procfs and sysfs, you only need the cat command. Fancy commands may require more system calls than supported by these file systems.

Before looking at the special applications for accessing procfs and sysfs, we need to know about HAL (the Hardware Abstraction Layer). It seems like we run into a new abstraction layer at every corner. At times, one wonders what is real among all the abstractions. HAL is an application that operates in user space (as opposed to the Windows NT HAL that operates in Kernel space), and maintains a database of hardware information. Application communicate with the HAL daemon via the D-Bus IPC. HAl obtains its information from /sys as does the udev daemon. While there is talk of Ubuntu replacing HAL with udev-extra, Ubuntu 9.10 still uses hald.

Thus, the Kernel identifies a new device and creates the kobjects for it, which are reflected in /sys. The udevd daemon uses this information to build a reference to the device in /dev and hald builds an D-Bus object for the device and notifies the appropriate applications. Knowing this chain of events is important to understanding the various applications that report hardware information, and how to use them for troubleshooting hardware problems.

Beyond using cat, cd, and ls to wander through /proc and /sys, there are the following tools:

• hwinfo – Available on Debian-based distros and openSUSE, hwinfo is the most comprehensive of all the tools.
• lshw – A similiar, but much less comprehensive tools, lshw is available on Fedora and Mandriva
• lshal – This utility is for those who love to read raw HAL information, as it only reports what HAL knows
• hwbrowser – A GUI application that tells you very little
• lsusb – An excellent tool for reporting only USB information, and it is available on most distros
• lspci – Same as lsusb, except that it reports on the PCI bus

While hwinfo provides both the /sys and HAL information, you can get the same information by using lshal in conjunction with the other tools. Just remember that if the device does not exist in /sys, it won’t exist in /dev, or in HAL’s database. If a device fails to install, you can usually find the error messages by using the dmesg command.