Comments
Matt McLarty wrote: For more info... Follow me on Twitter See our website
Cloud Expo on Google News


2008 West
DIAMOND SPONSOR:
Data Direct
SOA, WOA and Cloud Computing: The New Frontier for Data Services
PLATINUM SPONSORS:
Red Hat
The Opening of Virtualization
GOLD SPONSORS:
Appsense
User Environment Management – The Third Layer of the Desktop
Cordys
Cloud Computing for Business Agility
EMC
CMIS: A Multi-Vendor Proposal for a Service-Based Content Management Interoperability Standard
Freedom OSS
Practical SOA” Max Yankelevich
Intel
Architecting an Enterprise Service Router (ESR) – A Cost-Effective Way to Scale SOA Across the Enterprise
Sensedia
Return on Assests: Bringing Visibility to your SOA Strategy
Symantec
Managing Hybrid Endpoint Environments
VMWare
Game-Changing Technology for Enterprise Clouds and Applications
Click For 2008 West
Event Webcasts

2008 West
PLATINUM SPONSORS:
Appcelerator
Get ‘Rich’ Quick: Rapid Prototyping for RIA with ZERO Server Code
Keynote Systems
Designing for and Managing Performance in the New Frontier of Rich Internet Applications
GOLD SPONSORS:
ICEsoft
How Can AJAX Improve Homeland Security?
Isomorphic
Beyond Widgets: What a RIA Platform Should Offer
Oracle
REAs: Rich Enterprise Applications
Click For 2008 Event Webcasts
SYS-CON.TV
Top Links You Must Click On


Linux.SYS-CON.com: Device Management with udev and HAL on Fedora Core 4
Hotplugging everything on Fedora Core 4

This article discusses the implementation details for the new device management methods udev and HAL, now used on all Fedora Core 3 and 4 systems for all devices. It's time to relearn how devices are managed!

On Fedora Core 4, device files are no longer handled in a static way. Instead they're now dynamically generated as needed by udev and managed by HAL (Hardware Abstraction Layer). Previously a device file was created for each possible device, leading to a very large number of device files in the /etc/dev directory. Now, your system will detect only those devices it uses and create device files for those only, giving you a much smaller listing of device files. Both udev and HAL are hotplug systems, with udev used for creating devices and HAL designed for providing information about them, as well as managing the configuration for removable devices such as those with file systems like USB card readers and CD-ROMs.

Managing devices is at the same time easier but much more complex. You have to use udev and HAL to configure devices, though much of this is now automatic. Device information is maintained in a special device file system called sysfs located at /sys. This is a virtual file system like /proc and is used to keep track of all devices supported by the kernel.

In this article, I'll cover the initial basics of udev and HAL configuration and device management. The goal is to give you a sense of how devices are now managed on Fedora Core 4 and where to go to find the rules that now determine how devices are created.

udev: Device Files
Devices are now treated as hotplugged, meaning they can be easily attached and removed. Their configuration is dynamically detected and does not rely on manual administrative settings. The hotplug tool used to detect device files is udev, user devices. Each time your system is booted, udev will automatically detect your devices and generate device files for them in the /etc/dev directory. This means that the /etc/dev directory and its files are re-created each time you boot. It is a dynamic directory, no longer static. udev uses a set of rules to direct how device files are to be generated, including any corresponding symbolic links. These are located in the /etc/udev/rules.d files. As part of the hotplug system, udev will automatically detect kernel devices that are added or removed from the system. When the device interface is first created, its corresponding sysfs file is located and read, determining any additional attributes such as serial numbers and device major and minor numbers that can be used to uniquely identify the device. These can be used as keys in udev rules to create the device interface. Once the device is created, it's listed in the udev database, which keeps track of currently installed devices.

As /etc/dev is now dynamic, any changes you would make manually to the /etc/dev directory will be lost when you reboot. This includes the creation of any symbolic links such as /dev/cdrom that many software applications use. Instead, such symbolic links have to be configured in udev rules files located in the /etc/udev/rules.d directory. Default rules are already in place for the commonly used symbolic links, but you can create rules to add your own.

udev rules
udev uses the udev rules.d files to dynamically create your device files. The rules files already present in the rules.d directory have been provided for your Fedora Core distribution and are designed specifically for it. You should never modify these rules. To customize your setup, create your own separate rules files in /etc/udev/rules.d. In your rules file you would normally define only symlinks, using SYMLINK fields alone, as described in the following sections. These set up symbolic links to devices, letting you access them with other device names. NAME fields are used to create the original device interface, a task usually left to udev.

Each line maps a device attribute to a device name, as well as specifying any symbolic names (links). Attributes are specified using keys, of which there may be more than one. If all the keys match a device, then the associated name is used for it and a device file of that name will be generated. Instead of listing a device name, a program or script may be specified instead to generate the name. This is often the case for CD-ROM devices, where the device name could be a cdrecorder, cdrom, or dvdrom.

The key fields, such as KERNEL, support pattern matching to specify collections of devices. These operate as standard filename expansion operations: *, ?, [ ]". For example, mouse* will match all devices beginning with the pattern "mouse". The following field uses the KERNEL key to match on all mouse devices as listed by the kernel:

KERNEL="mouse*"

The next key will match on all printer devices numbered lp0 through lp9. It uses brackets to specify a range of numbers or characters, in this case 0 through 9, [0-9]:

KERNEL="lp[0-9]*"

The NAME, SYMLINK, and PROGRAM fields support string substitution codes similar to the way printf codes work. Such a code is preceded by a % symbol. The code allows several possible devices and names to be referenced in the same rule. For example, %k references the kernel name for a device.

The udev Man page provides many examples of udev rules using various fields. On Fedora Core 4, the 50-udev.rules file holds rules that primarily use KERNEL keys to designate devices. The KERNEL key is followed by either a NAME field to specify the device filename or a SYMLINK field to set up a symbolic link for a device file. The following rule uses the KERNEL key to match on all mouse devices as listed by the kernel. Corresponding device names are placed in the /dev/input directory, and the name used is the kernel name for the device (%k):

KERNEL="mouse*", NAME="input/%k"

You can use more then one key in a rule. The following rule uses both a BUS key and a KERNEL key to set up device files for USB printers, whose kernel names will be used to create device files in /dev/usb:

BUS="usb", KERNEL="lp[0-9]*", NAME="usb/%k"

Symbolic Links
Certain device files are really symbolic links bearing common device names that are often linked to the actual device file used. A symbolic link is another name for a file that is used like a shortcut, referencing that file. Common devices such as printer, CD-ROM, hard drive, SCSI, and sound devices, along with many others, will have corresponding symbolic links. For example, a /dev/cdrom symbolic link links to the actual device file used for your CD-ROM.

Symbolic links are created by udev using the SYMLINK field. The symbolic links for a device can be listed either with the same rule creating a device file or in a separate rule that will specify only a symbolic link. Rules that specify a symbolic link only will have just a SYMLINK field with no NAME field. In this case the symbolic link is kept on a list awaiting the creation of its device. This allows you to add other symbolic links for a device in other rules files. For example, you could create your own rules file with symbolic links for devices. Such a file would have rules that used just SYMLINK fields for devices. Rules with NAME fields would be still be handled by the original udev rule files like 50-rules.udev.

About Richard Petersen
Richard Petersen holds a M.L.I.S. in Library and Information Studies. He
currently teaches Unix and C/C++ courses at the University of California, Berkeley.

In order to post a comment you need to be registered and logged in.

Register | Sign-in

Reader Feedback: Page 1 of 1

LinuxWorld: Device Management with udev and HAL on Fedora Core 4. This article discusses the implementation details for the new device management methods udev and HAL, now used on all Fedora Core 3 and 4 systems for all devices. It's time to relearn how devices are managed!


Your Feedback
LinuxWorld News Desk wrote: LinuxWorld: Device Management with udev and HAL on Fedora Core 4. This article discusses the implementation details for the new device management methods udev and HAL, now used on all Fedora Core 3 and 4 systems for all devices. It's time to relearn how devices are managed!
Enterprise Open Source Magazine Latest Stories . . .
Cloud computing is creating the new Wall Street boom, according to NIA. The only industry that is as bright as cloud computing on Wall Street is social networking, NIA said in a recent report. 2012 will be known as the year cloud computing became widely adopted worldwide. Cloud comput...
The impact of Big Data is extremely broad for business, information management and technology. Being able to analyze your growing mountain of data can give you a distinct competitive advantage, but Big Data can be more than traditional tools can handle. In his session at the 10th Int...
In this CTO Power Panel at the 10th International Cloud Expo, moderated by Cloud Expo Conference Chair Jeremy Geelan, industry-leading CTOs & VPs of Technology will discuss such topics as: Which do you think is the most important cloud computing standard still to tackle? Who should...
China’s antitrust regulators gave Google’s $12.5 billion acquisition of Motorola Mobility the nod Saturday provided Google’s Android operating system remains open and free-of-charge for the next five years. The “free” stipulation apparently doesn’t apply to applications or services...
If your organization already uses virtualized infrastructure, you are well on your way to providing IT as a Service. But as businesses demand faster results in today’s competitive market, organizations look to gain more benefits from cloud computing than just virtualized infrastructure...
Citrix has acquired Virtual Computer, a little Massachusetts outfit with enterprise-scale management solutions for client-side virtualization. It means to combine the acquisition’s NxTop widgetry with its XenClient hypervisor to create a new Citrix XenClient Enterprise edition that c...
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
Click to Add our RSS Feeds to the Service of Your Choice:
Google Reader or Homepage Add to My Yahoo! Subscribe with Bloglines Subscribe in NewsGator Online
myFeedster Add to My AOL Subscribe in Rojo Add 'Hugg' to Newsburst from CNET News.com Kinja Digest View Additional SYS-CON Feeds
Publish Your Article! Please send it to editorial(at)sys-con.com!

Advertise on this site! Contact advertising(at)sys-con.com! 201 802-3021


SYS-CON Featured Whitepapers
ADS BY GOOGLE