- Denial: System V Init
- Anger: Upstart
- Bargaining: Backward Compatibility
- Depression: udev
- Acceptance
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Depression: udev
If you're a longtime Linux user and want a shock, start a rescue CD on an Ubuntu system, mount your root file system, and then check the /dev directory. Where did your files go? In addition to replacing init, Ubuntu also replaced static device files in /dev with dynamic ones governed by the udev system.
In the old days, the /dev/ directory was full of special device files for just about every device you could ever imagine connecting to a Linux system. When you added new hardware support to your kernel, you also had to create the special device files for that hardware under /dev. In the current scheme, as new hardware is detected on the system, udev works to create the device entries and perform other related tasks. It also replaces tools such as hotplug that manage devices (such as USB drives) that might be added to the system after boot.
In many ways, udev works like Upstart. udev stores its configuration under /etc/udev and stores rules under /etc/udev/rules.d. These rules can match a number of hardware events on the system, including device events (such as when you plug in a USB drive), device attributes (specific vendor IDs or device paths), or variables set up by other rules. Once a rule is triggered, it can define certain actions, such as loading modules, creating device files, or running external programs. With udev, you no longer have a /dev directory littered with devices that don't exist; instead, the /dev/ directory reflects a more accurate view of your computer's hardware.
The downside to udev rules is that the syntax wasn't designed to be user-friendly. In fact, the syntax in many of the default rules is downright hostile. However, it isn't too tricky to set up your own udev rule. For instance, I used a Sierra wireless 3G PCMCIA card to get a cellular Internet connection. I didn't like that I had to run ifup ppp0 each time I inserted the card; I figured there must be some way to automate the process. As I learned, once the card was detected, it created a series of /dev/ttyUSB devices from 0 through 5. If I could track down a unique product ID for the device, I could trigger a udev rule that would run ifup ppp0 for me when it saw that the device was added.
The first thing I did was find this (somewhat convoluted) one-liner in the udev documentation that would output udev information about a device based on its device path:
# udevinfo -a -p $(udevinfo -q path -n /dev/ttyUSB0)
When I ran this command, I discovered an idProduct key that was set to 6880 and seemed unique for this type of card. I then created a file named /etc/udev/rules.d/95-sierra.rules with the following rules:
KERNELS=="5-1", ATTRS{idProduct}=="6880", ENV{ACTION}=="add",
RUN+="/sbin/ifup ppp0"
KERNELS=="5-1", ATTRS{idProduct}=="6880", ENV{ACTION}=="remove",
RUN+="/sbin/ifdown ppp0"
The first line detects when the device is added and runs /sbin/ifup ppp0, and the second line runs /sbin/ifdown ppp0 when it sees that the device has been removed. Granted, the syntax could be simpler, but for basic rules like this it's simple enough to create your own rule, once you have something to use as a base.