Penguin
Annotated edit history of UDev version 10, including all changes. View license author blame.
Rev Author # Line
10 LawrenceDoliveiro 1 __udev__ is the UserSpace-based replacement for DevFs, an obsolete LinuxKernel [Module] that creates entries for available devices in <tt>/dev</tt>. <tt>udev</tt> is available in [Kernel] 2.5 and newer and uses HotPlug and the SysFs FileSystem.
7 IanMcDonald 2
10 LawrenceDoliveiro 3 The home page for <tt>udev</tt> is at http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
3 StuartYeates 4
4 AristotlePagaltzis 5 See also:
6 * [Red Hat Magazine - Configuring Devices with udev | http://www.redhat.com/magazine/002dec04/features/udev/]
5 CraigBox 7 * [Writing udev rules|http://www.reactivated.net/udevrules.php]
6 CraigBox 8 * [Gentoo Customizing udev HOWTO|http://gentoo-wiki.com/HOWTO_Customizing_UDEV]
3 StuartYeates 9 ----
6 CraigBox 10
11 !!Notes
12 (WikiGnome~s split out to another page if you feel the need)
3 StuartYeates 13
4 AristotlePagaltzis 14 !! Troubleshooting
15
16 __Q:__ Why doesn't the [HAL] and [UDev] combination pick up my device events (ie plugging in a KeyDrive) in DebianLinux?
17 <br> __A:__ You have to add the user to the "plugdev" group, else it won't work.
6 CraigBox 18
19 !! Force a USB storage device to a specific mount point
20
21 DanielLawson writes on the [NZLUG] list:
22
23 There are a couple of ways of doing this.
24
25 If your distribution uses udev, you can make a udev rule to create a /dev entry for a specific device, based on some criteria. I've used the USB serial #, for example, to map my USB harddisk to /dev/external and my USB flash disk to /dev/memorystick. You can then use normal fstab rules for these mounts.
26
27 Another option, which works with most FileSystem~s (not [NTFS] it seems), is to get the UUID of the filesystem, and use that as an fstab(5) rule. If you run the blkid program as root it will list all filesystems present
28 on your system, and their UUIDs if they are available. You can then add a rule to fstab that looks like:
29
30 =UUID=42CB-5356 /media/external vfat rw,user,noauto 0 0=
31
32 blkid is provided by the libblkid1 package under [Ubuntu] (and [Debian] Sarge, I believe).
33
34 These approaches should all integrate reasonably well with the standard automounting facilities available in modern distributions.
8 IanMcDonald 35
36 !! Locking down a device name
37
38 If you have multiple sound cards, network cards or multiple any device the kernel might change the order randomly. One time eth0 will be one card and eth1 the other - next time it might be eth1 for the first card and udev doesn't seem to be able to override this. To get around this use udev to call them a different name e.g. lan0 and lan1. Your eth0 and eth1 will still exist but use the lan0 and lan1 in other areas instead.
9 zcat(1) 39
40
41 !! zcat's maddening experience with sound devices
42
43 If you have multiple soundcards you will quickly discover that each of the various devices (/dev/dsp, /dev/audio, /dev/mixer) all point to the same piece of hardware, so consequently all those useful identifiers like SYSFS{device} are identical. The only thing that changes between pseudo-devices on the same card is the kernel-allocated and randomly changing kernel device and node numbers. My Head A-Splode!
44
45 The guide to writing udev rules (link above) says you cannot generally mix the logical and physical device parts, but later examples do exactly that and I finally came to the conclusion this is the ONLY way to sort out audio devices.
46
47 I also decided that If I'm manually defining _all_ the sound devices, forcing the second card to be /dev/dsp1 and so on then there is never going to be a name clash so it should be fairly safe to reuse names the kernel allocates automatically (this assumption might break if I ever plug in a non-forced soundcard, but I'll deal with that when/if it becomes a problem.)
48
49 SO; my rules look for something to identify the card (ID==0000:00:08.0 will always be the card in that particular PCI slot, I could equally use SYSFS{vendor} or DRIVER to identify the same card in any slot) and something to identify the device on that card (kernel="dsp*" will match the dsp device, whatever number the kernel was thinking of giving it) and then force a new name onto it. Repeat for each sound device, and again for each card.
50
51 Anyhow, here's the rules I came up with to reliably keep by two PCI cards in their fixed positions. It probably isn't the idea solution, but it works! They even swap over when I tell them to!
52
53
54 <pre>
55 /etc/udev/rules.d/10-local.rules
56
57 BUS=="pci", ID=="0000:00:07.0" KERNEL=="mixer*", NAME="mixer"
58 BUS=="pci", ID=="0000:00:07.0" KERNEL=="midi*", NAME="midi"
59 BUS=="pci", ID=="0000:00:07.0" KERNEL=="dsp*", NAME="dsp"
60 BUS=="pci", ID=="0000:00:07.0" KERNEL=="audio*", NAME="audio"
61 BUS=="pci", ID=="0000:00:07.0" KERNEL=="audio*", NAME="adsp"
62 BUS=="pci", ID=="0000:00:07.0" KERNEL=="audio*", NAME="dmmidi"
63 BUS=="pci", ID=="0000:00:07.0" KERNEL=="audio*", NAME="dmfm"
64
65 BUS=="pci", ID=="0000:00:08.0" KERNEL=="mixer*", NAME="mixer1"
66 BUS=="pci", ID=="0000:00:08.0" KERNEL=="midi*", NAME="midi1"
67 BUS=="pci", ID=="0000:00:08.0" KERNEL=="dsp*", NAME="dsp1"
68 BUS=="pci", ID=="0000:00:08.0" KERNEL=="audio*", NAME="audio1"
69 BUS=="pci", ID=="0000:00:08.0" KERNEL=="audio*", NAME="adsp1"
70 BUS=="pci", ID=="0000:00:08.0" KERNEL=="audio*", NAME="dmmidi1"
71 BUS=="pci", ID=="0000:00:08.0" KERNEL=="audio*", NAME="dmfm1"
72
73 </pre>

PHP Warning

lib/blame.php:177: Warning: Invalid argument supplied for foreach()