When Linux-users talk about the hardware on their system in the vicinity of people who believe Linux is some sort of virus or brand of coffee, the use of "slash dev slash foo" will return a strange look for sure. But for the fortunate user (and that includes you) using /dev/hda1 is just a fast way of explaining that we are talking about the primary master IDE, first partition. Or aren't we?

We all know what a device file is. Some even know why device files have special numbers when we take a closer look at them when we issue ls -l in /dev. But what we always take for granted is that the primary master IDE disk is referred to as /dev/hda. You might not see it this way, but this is a flaw by design.

Think about hotpluggable devices like USB, IEEE1394, hot-swappable PCI, ... What is the first device? And for how long? What will the other devices be named when the first one disappears? How will that affect ongoing transactions? Wouldn't it be fun that a printing job is suddenly moved from your supernew laserprinter to your almost-dead matrix printer because your mom decided to pull the plug of the laserprinter which happened to be the first printer?

Enter udev. The goals of the udev project are both interesting and needed:

• Runs in userspace
• Dynamically creates/removes device files
• Provides consistent naming
• Provides a user-space API

Every time a change happens within the device structure, the kernel emits a uevent which gets picked up by udev. udev then follows the rules as declared in the /etc/udev/rules.d and /lib/udev/rules.d directories. Based on the information contained within the uevent, it finds the rule or rules it needs to trigger and performs the required actions. These actions can be creating or deleting device files, but can also trigger the loading of particular firmware files into the kernel memory.

udev is meant to be used in combination with a 2.6 kernel (like gentoo-sources with the default 10.0 profile). If you're using such a kernel then you just should have no issues whatsoever with using udev as the necessary support is built-in in all stable sys-apps/baselayout versions. Normally, udev should already be installed on your system, but if this is not the case, then it is easy to install:

# emerge udev

Kernelwise, be sure to activate the following options:

General Setup --->
  (Make sure the following item is *not* enabled)
  [ ] enable deprecated sysfs features to support old userspace tools

File Systems --->
  [*] Inotify support for userspace
  Pseudo filesystems --->
    [*] Virtual memory file system support (former shm fs)

If you use genkernel, you don't need to do anything special. Genkernel sets up udev by default.

If you can't boot successfully because you get an error about /dev/null not found, or because the initial console is missing, the problem is that you lack some device files that must be available before /dev is mounted and handled by udev. This is common on Gentoo machines installed from old media.

If you run sys-apps/baselayout-1.8.12 or later, this problem is alleviated since the boot process should still manage to complete. However, to get rid of those annoying warnings, you should create the missing device nodes as described below.

To see which devices nodes are present before the /dev filesystem is mounted, run the following commands:

# mkdir test
# mount --bind / test
# cd test/dev
# ls

The devices needed for a successful boot are /dev/null and /dev/console. If they didn't show up in the previous test, you have to create them manually. Issue the following commands in the test/dev/ directory:

# mknod -m 660 console c 5 1
# mknod -m 660 null c 1 3

When you're finished, don't forget to unmount the test/ directory:

# cd ../..
# umount test
# rmdir test

If you use the proprietary driver from nVidia and the X server fails to start on a udev-only system, then make sure you have:

• the nvidia module listed in /etc/modules.autoload.d/kernel-2.6
• a version of baselayout equal to or greater than sys-apps/baselayout-1.8.12

Even though our intention is to have a consistent naming scheme between both dynamical device management solutions, sometimes naming differences do occur.

One reported clash is with a HP Smart Array 5i RAID controller (more precisely the cciss kernel module). With udev, the devices are named /dev/cciss/cXdYpZ with X, Y and Z regular numbers. With devfs, the devices are /dev/hostX/targetY/partZ or symlinked from /dev/cciss/cXdY.

If this is the case, don't forget to update your /etc/fstab and bootloader configuration files accordingly.

The same happens with all-round symlinks that used to exist in /dev, such as /dev/mouse, which udev doesn't create anymore. Be certain to check your X configuration file and see if the Device rule for your mouse points to an existing device file.

Another issue is the difference in naming of terminals between devfs and udev. While devfs calls its terminals tty, udev calls them vc and tty. This could lead to a problem in case you are restricting root logins from consoles using /etc/securetty. You will need to make sure that both tty1 and vc/1 are listed in /etc/securetty to ensure that root can login using the console.

Recent versions of udev (104 and up) along with newer kernel versions (2.6.19 and up) may change your disc device names, due to a change in the kernel's libata implementation. A CD-RW device at /dev/hdc may be changed to /dev/sr0. While this is not normally a problem, it may cause issues for some applications that are hardcoded to look for devices at other locations. For example, media-sound/rip expects to find discs at /dev/cdrom, which becomes a problem if you use a newer kernel and udev renames your device to /dev/cdrom1.

To work around these issues, you must edit /etc/udev/rules.d/70-persistent-cd.rules and assign the correct name to the device.

For more information on writing udev rules, be sure to read Daniel Drake's guide.

Sometimes unplugging and replugging a network device (like a USB WiFi card) can rename your net device each time, incrementing the number by one.

When this happens, you'll see it become wlan0, wlan1, wlan2, etc. This is because udev is adding additional rules to its rules file, instead of reloading the existing rules. Since udev watches its rules directory via inotify, you need inotify support in your kernel config:

File systems --->
    [*] Inotify file change notification support
    [*]   Inotify support for userspace

Now udev will retain proper names for your network devices.

Sometimes udev loads modules in an undesired, unpredictable, or seemingly random order. This is especially common for systems that have multiple devices of the same type, as well as multimedia devices. This can affect the assigned numbers of devices; for example, sound cards may sometimes swap numbers.

There are a few solutions to fix device numbers and/or module load order. Ideally, you can just use module parameters to specify your desired device number. Some modules, such as ALSA, include the "index" parameter. Modules that use the index parameter can be adjusted as shown. This example is for a system with two sound cards. The card with an index of 0 is designated as the first card. Once the parameters are changed, the module config files must be updated.

# echo "option snd-ice1724 index=0" >> /etc/modprobe.d/alsa.conf
# echo "option snd-ymfpci index=1" >> /etc/modprobe.d/alsa.conf
# update-modules

The above example is the preferred solution, but not all modules support parameters such as index. For these modules, you'll have to force the correct module load order. First, you must stop udev from autoloading the modules by blacklisting them. Be sure to use the exact name of the module being loaded. For PCI devices, you'll need to use the module names obtained from the output of lspci -k, available in the pciutils package. The following example uses DVB modules.

# echo "blacklist b2c2-flexcop-pci" >> /etc/modprobe.d/dvb
# echo "blacklist budget" >> /etc/modprobe.d/dvb
# update-modules

Next, load the modules in the correct order. Add them to /etc/modules.autoload.d/kernel-2.6 in the exact order you want them loaded.

# echo "budget" >> /etc/modules.autoload.d/kernel-2.6
# echo "b2c2-flexcop-pci" >> /etc/modules.autoload.d/kernel-2.6

If device nodes are not created when a module is loaded from /etc/modules.autoload.d/kernel-2.6 but they appear when you load the module manually with modprobe then you should try upgrading to sys-apps/baselayout-1.8.12 or later.

Support for the framebuffer devices (/dev/fb/*) comes with the kernel starting from version 2.6.6-rc2.

For kernels older than 2.6.4 you have to explicitly include support for the /dev/pts filesystem.

File systems --->
  Pseudo filesystems --->
    [*] /dev/pts file system for Unix98 PTYs

The udev talk on the Linux Symposium (Ottawa, Ontario Canada - 2003) given by Greg Kroah-Hartman (IBM Corporation) provided a solid understanding on the udev application.

Decibel's UDEV Primer is an in-depth document about udev and Gentoo.

Writing udev rules by fellow Gentoo developer Daniel Drake is an excellent document to learn how to customize your udev installation.