1 .TH UDEV 8 "October 2003" "" "Linux Administrator's Manual"
3 udev \- Linux configurable dynamic device naming support
5 .BI udev " hotplug-subsystem"
7 The environment must provide the following variables:
11 signifies the connection or disconnection of a device.
14 The sysfs devpath of the device without the mountpoint but a leading slash.
16 Additional optional environment variables are:
19 Overrides the default location of the
24 The default behavior of
26 is to wait until all the sysfs files of the device chain are populated. If set
28 will will continue, regardless of the state of the device representation.
31 creates or removes device node files usually located in the /dev directory.
32 It provides a dynamic device directory that contains only the files for
33 devices that are actually present.
39 is executed if a kernel device is added or removed from the system.
42 reads the sysfs directory of the given device to collect device attributes
43 like label, serial number or bus device number.
44 These attributes may used as keys to determine a
45 unique name for device file creation.
47 maintains a database for devices present on the system.
51 queries its database for the name of the device file to be deleted.
55 configuration files consist of a set of lines of text. All empty
56 lines, and lines beginning with a '#' will be ignored.
60 expects its main configuration file at
61 .IR /etc/udev/udev.conf .
62 The file consists of a set of variables and values that allow the user to
63 override default udev values. The current set of variables that can be
64 overridden in this file is:
67 This is the where in the filesystem to place the device nodes. The default
72 The name and location of the udev database. The default value for this is
76 This is the location of the udev rules file. The default value for this is
77 .IR /etc/udev/udev.rules .
78 If a directory is specified, the whole directory is
79 scanned for files ending with
81 and all rule files are read in lexical order.
84 This is the location of the udev permission file. The default value for this is
85 .IR /etc/udev/udev.permissions .
86 If a directory is specified, the whole directory is scanned for files ending with
88 and all permission files are read in lexical order.
91 If you want udev to log some information to the syslog for every node created or
92 removed. The default value for this is
96 This is the default mode for all nodes that have no explicit match in the
97 permissions file. The default value for this is
101 This is the default owner for all nodes that have no explicit match in the
102 permissions file. The default value for this is
106 This is the default group for all nodes that have no explicit match in the
107 permissions file. The default value for this is
111 .RI "A sample " udev.conf " might look like this:
114 # udev_root - where in the filesystem to place the device nodes
117 # udev_db - The name and location of the udev database.
118 udev_db="/udev/.udev.tdb"
120 # udev_rules - The location of the directory where to look for files
121 which names ending with .rules
122 udev_rules="/etc/udev/"
124 # udev_permissions - The name and location of the udev permission file
125 udev_permissions="/etc/udev/udev.permissions"
127 # udev_log - set to "yes" if you want logging, else "no"
130 # default_mode - set the default mode for all nodes that have no
131 # explicit match in the permissions file
134 # default_owner - set the default owner for all nodes that have no
135 # explicit match in the permissions file
138 # default_group - set the default group for all nodes that have no
139 # explicit match in the permissions file
143 The rules for udev to use when naming devices may specified at
144 .I /etc/udev/udev.rules
148 .I /etc/udev/udev.conf
151 Every line in the rules file defines the mapping between device attributes
152 and the device file name. One ore more keys are specified to match a rule
153 with the current device. If all keys are matching, the rule will be applied
154 and the name is used for the device node. One or more optional symlinks
155 targeting the node may be specified.
157 If no matching rule is found, the default kernel device name is used.
161 .I key,[key,...] name [, symlink]
166 Match the bus type of the device.
167 (The sysfs device bus must be able to be determined by a "device" symlink.)
170 Match the kernel device name.
173 Match the device number on the bus, like PCI bus id.
176 Match the topological position on bus, like physical port of USB device
178 .BI SYSFS{ filename }
179 Match sysfs device attribute like label, vendor, USB serial number, SCSI UUID
180 or file system label. Up to 5 different sysfs files can be checked, with
181 all of the values being required in order to match the rule.
184 Call external program. This key is valid if the program returns successful.
185 The environment variables of
187 are also available for the program.
189 The string returned by the program may additionally matched with the
194 Match the returned string of the last
196 call. This key may used in any following rule after a
202 field given with the attribute
203 .BR NAME{ all_partitions }
204 will create all 15 partitions of a blockdevice.
205 This may be useful for removable media devices.
207 .RB "The " NAME " ," SYMLINK " and " PROGRAM
208 fields support simple printf-like string substitution:
211 The "kernel number" of the device.
212 for example, 'sda3' has a "kernel number" of '3'
215 The "kernel name" for the device.
218 The kernel major number for the device.
221 The kernel minor number for the device.
224 The bus id for the device.
230 (This does not work within the
232 field for the obvious reason.)
234 A single part of the string, separated by the space character
235 my be selected by specifying the part number as a attribute:
239 The content of a sysfs attribute.
244 .RI "A sample " udev.rules " might look like this:"
247 # if /sbin/scsi_id returns "OEM 0815" device will be called disk1
248 BUS="scsi", PROGRAM="/sbin/scsi_id", RESULT="OEM 0815", NAME="disk1"
250 # USB printer to be called lp_color
251 BUS="usb", SYSFS{serial}="W09090207101241330", NAME="lp_color"
253 # SCSI disk with a specific vendor and model number is to be called boot
254 BUS="scsi", SYSFS{vendor}="IBM", SYSFS{model}="ST336", NAME="boot%n"
256 # sound card with PCI bus id 00:0b.0 to be called dsp
257 BUS="pci", ID="00:0b.0", NAME="dsp"
259 # USB mouse at third port of the second hub to be called mouse1
260 BUS="usb", PLACE="2.3", NAME="mouse1"
262 # ttyUSB1 should always be called pda with two additional symlinks
263 KERNEL="ttyUSB1", NAME="pda", SYMLINK="palmtop handheld"
265 # multiple USB webcams with symlinks to be called webcam0, webcam1, ...
266 BUS="usb", SYSFS{model}="XV3", NAME="video%n", SYMLINK="webcam%n"
269 Permissions and ownership for the created device files may specified at
270 .I /etc/udev/udev.permissions
274 .I /etc/udev/udev.conf
277 Every line lists a device name followed by owner, group and permission
278 mode. All values are separated by colons. The name field may contain a
279 pattern to apply the values to a whole class of devices.
281 .RI "A sample " udev.permissions " might look like this:"
284 #name:user:group:mode
285 input/*:root:root:644
287 video*:root:video:0660
291 A number of different fields in the above configuration files support a simple
292 form of shell style pattern matching. It supports the following pattern characters:
295 Matches zero, one, or more characters.
298 Matches any single character, but does not match zero characters.
301 Matches any single character specified within the brackets. For example, the
302 pattern string "tty[SR]" would match either "ttyS" or "ttyR". Ranges are also
303 supported within this match with the '-' character. For example, to match on
304 the range of all digits, the pattern [0-9] would be used. If the first character
305 following the '[' is a '!' then any character not enclosed is matched.
308 /sbin/udev udev program
309 /etc/udev/* udev config files
310 /etc/hotplug.d/default/udev.hotplug hotplug symlink to udev program
319 .I http://linux-hotplug.sourceforge.net/
323 was developed by Greg Kroah-Hartman <greg@kroah.com> with much help from
324 Dan Stekloff <dsteklof@us.ibm.com>, Kay Sievers <kay.sievers@vrfy.org>, and