1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
|
How does udev work?
~~~~~~~~~~~~~~~~~~~
Short summary: when a driver is loaded it makes some information available
in /sys/ and a message is sent to udevd which reads them and creates the
appropriate devices.
This means that:
- modules cannot be loaded on demand when applications open their device,
because the device is not yet there!
- since modules are not loaded on demand, if for some reason the drivers
cannot be automatically loaded at boot time you will have to add them
to /etc/modules.
- some modules are not hardware drivers and cannot be loaded automatically
by udev, so they will have to be listed in /etc/modules as well.
- some modules, like the drivers for some ISA PNP devices, lack the
sysfs data needed to be automatically loaded and must be loaded manually.
(See #334238 and #337004 for details.)
- some drivers have not been ported to sysfs yet, and udev will not be
able to create their devices. If you use one of these drivers you will
have to create the devices after every boot.
- some drivers, like the md kernel RAID drivers, have design problems and
will require further development before they will fully work with udev.
See http://groups.google.com/groups?threadm=1VPLh-6f9-11%40gated-at.bofh.it
and #294404 for details. Possible workarounds are manual creation of
the /dev/md* devices or kernel autostart of the RAID volumes.
In other words, on a typical system you may need to manually load
(using /etc/modules) modules like ppdev and tun.
udevd also manages the hotplug events and if needed dispatches them to
other programs using RUN rules, as a replacement of the old /sbin/hotplug.
The hotplug package is not needed anymore and is disabled when udev is
installed, so it should be removed.
Kernel support needed
~~~~~~~~~~~~~~~~~~~~~
The running kernel must be not older than 2.6.15 and must support the
hotplug subsystem (CONFIG_HOTPLUG) and tmpfs (CONFIG_TMPFS).
CONFIG_PNP, CONFIG_ISAPNP, CONFIG_PNPBIOS and CONFIG_PNPACPI are highly
recommended to allow to automatically load some important drivers.
udev 059 is needed to properly support rules referencing sysfs attributes
since kernel 2.6.12.
udev 072 is needed to properly support the input subsystem since kernel
2.6.15.
udev 096 is needed to properly support path_id (i.e. persistent names)
since kernel 2.6.18.
Disabling udev
~~~~~~~~~~~~~~
You may configure in /etc/udev/udev.conf a directory other than /dev.
Naming policy
~~~~~~~~~~~~~
The default configuration uses a traditional /dev layout. Naming style
is controlled by the contents of the /etc/udev/rules.d/ directory.
The default is a symlink to /etc/udev/udev.rules, and only files with
the .rules extension will be considered.
The package will not modify the symlinks contained in the directory,
except when new rules files are added to the package.
You may also create there a file with your own rules.
The rules file devfs.rules (along with compat.rules and compat-full.rules)
is provided to support devfs-style names, but it's deprecated and its use
is highly discouraged.
Do not forget that even if you use devfs-style names, your kernel will
not know about them unless you compile in devfs support. If you do not,
then you will have to use traditional names e.g. as the argument of the
root= boot parameter.
The /etc/udev/rules.d/ directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The files are read and processed in alphabetical order, and the the
directives of matching rules are applied in order. The only exceptions
are NAME attributes, of which only the first one is considered.
Since the order is important, some file names have a specific name which
must be considered when adding custom rules. So far have been defined:
- 020: the default permissions and owners are set.
- z20: storage-related persistent names and $ID_PATH are set.
- z25: other persistent names are set.
- z50: $REMOVE_CMD is run, and then processing of tty devices
is stopped with last_rule.
- z70: last_rule options end processing of "drivers" and "module"
hotplug events and the hotplug.d/ and dev.d/ legacy scripts are run.
The persistent-*.rules files are generated by the *-generator.rules files
using the /lib/udev/write_*_rules scripts when new devices are detected.
They set stable names for network interfaces and optical devices aliases.
MAINTAINERS BEWARE: the use of /etc/udev/rules.d/ by other packages is
discouraged, except when only RUN rules are added.
If you think your package needs to create a file there, then please
contact the udev package maintainer and explain your needs.
Packages should NEVER create files in /etc/udev/rules.d/, but create a
symlink the first time the package is installed (and never try again, to
allow the local system administrator to remove it).
How to know the attributes of a device
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Try something like: udevinfo -a -p /sys/class/sound/pcmC0D0c/ .
/usr/share/doc/udev/examples/udevtest-all may be useful as well.
Removing this package
~~~~~~~~~~~~~~~~~~~~~
When the udev package is removed, the /dev tmpfs is left mounted so you
are advised to reboot as soon as possible because further changes to
/dev will be lost.
If you understand the consequences of these commands, you can try to
manually restore the old /dev with a procedure like:
mkdir /tmp/tempdev
mount -n --move /dev /tmp/tempdev
/etc/init.d/mountvirtfs start
/etc/init.d/sysklogd restart
/etc/init.d/gpm restart
umount /tmp/tempdev
rmdir /tmp/tempdev
Devices timestamps
~~~~~~~~~~~~~~~~~~
Most devices will be created at the beginning of the boot process, and will
have the creation time of the kernel clock at that moment.
On systems whose system clock is set on local time instead of UTC, the
kernel clock will be updated in a later phase of the boot process and for
a few hours the devices will have a timestamp in the future.
This is usually not a problem, but if it bothers you it can be fixed by
running touch(1) in an init script.
SCSI block and generic devices
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
When you create a custom rule which matches SCSI devices by some SYSFS
attributes, do not forget that it will match not only the sdX device node
you are probably looking for but also the SCSI generic device node sgX.
To get the expected behaviour, you need to add KERNEL="sd*" to your rule.
A typical example for an USB pen drive is:
SUBSYSTEMS=="usb", KERNEL=="sd*", \
ATTRS{manufacturer}=="hardware vendor", ATTRS{product}=="model", \
SYMLINK+="pendrive%n"
If a device does not report media changes (like e.g. many SD card readers)
you will also need to add the OPTIONS+="all_partitions" attribute to the
rule. This is not needed if you are using HAL.
Network Interfaces
~~~~~~~~~~~~~~~~~~
After receiving events about network interfaces, net.agent will call
ifupdown using the --allow=hotplug option. This makes the program act
only on interfaces marked with the "allow-hotplug" statement.
E.g: "allow-hotplug eth0" instead of the usual "auto eth0".
The loopback interface must always be configured with "auto lo".
The persistent names of network interfaces by default are automatically
written to /etc/udev/rules.d/z25_persistent-net.rules .
Users can add their own rules there or at any other place before z45.
Generation of rules for persistent names can be disabled by removing
the z45_persistent-net-generator.rules symlink.
Beware: programs which rename network interfaces like ifrename and nameif
will let udev relay events for the old names and should not be used.
This may not work reliably for some devices used with kernels older than
2.6.20 (see #389250 for details).
Devices enumeration
~~~~~~~~~~~~~~~~~~~
The %e parameter for device names does not work as expected, because the
hotplug events which trigger the creation of device nodes are processed
asyncronously. The result is that the value of %e may change after a reboot.
The cd-aliases-generator.rules rules file will automatically generate
rules to create the aliases like /dev/cdrom.
For the same reason, kernel drivers are loaded in a random order and
network interfaces or device names may change their position after a reboot.
Using udev with LDAP or NIS
~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the rules files reference usernames or groups not present in the
/etc/{passwd,groups} files and the system is configured to use a
network-based database like LDAP or NIS then udev may fail at boot time
because users and groups are looked up well before the network has been
initialized.
A possible solution is to configure /etc/nsswitch.conf like this:
passwd: files ldap [UNAVAIL=return]
group: files ldap [UNAVAIL=return]
The nsswitch.conf syntax is documented in the glibc manual.
Other documentation
~~~~~~~~~~~~~~~~~~~
http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev.html
http://www.reactivated.net/udevrules.php
http://www.kroah.com/linux/talks/suse_2005_driver_model/
|
