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/] | ||
3 | StuartYeates | 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 | |
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> |
lib/blame.php:177: Warning: Invalid argument supplied for foreach()