.SH NAME
udev \- Linux configurable dynamic device naming support
.SH SYNOPSIS
-.B udev
+.BI udev " hotplug-subsystem"
.SH "DESCRIPTION"
.B udev
creates or removes device node files usually located in the /dev directory.
+Its goal is to provide a dynamic device directory that contains only the files
+for devices that are actually present.
+.P
As part of the
.B hotplug
subsystem,
.B udev
-is exectuted if a kernel device is added or removed from the system.
-.P
+is executed if a kernel device is added or removed from the system.
On device creation,
.B udev
-reads the sysfs directory of the given device, to collect device attributes
+reads the sysfs directory of the given device to collect device attributes
like label, serial number or bus device number.
-These attributes are passed as a key to the namedev subsystem
-to receive a unique name for device file creation.
-namedev maintains a database for devices present on the system.
-.P
+These attributes are treated as a key
+to determine a unique name for device file creation.
+.B udev
+maintains a database for devices present on the system.
+.br
On device removal,
.B udev
-queries the namedev database for the name of the device file to delete.
-.P
-namedev expects its configuration at
-.I /etc/udev/namedev.config.
+queries the internal database for the name of the device file to be deleted.
+.SH "CONFIGURATION"
+.B udev
+expects its configuration at
+.I /etc/udev/udev.config.
The file consists of a set of lines. All empty lines and
lines beginning with a '#' will be ignored.
.br
Every line defines the mapping between device attributes and the device file
name. It starts with a keyword defining the method used to match, followed by
-one ore more keys to compare, optional ownwership and permission settings and
-the filename for the device. If no matching configuration is found,
-the default kernel device name is used.
+one ore more keys to compare and the filename for the device. If no matching
+configuration is found, the default kernel device name is used.
.P
-.I method, key,[key,...] [owner,] [group,] [mode,] name
+The line format is:
+.RS
+.sp
+.I method, key,[key,...] name
+.sp
+.RE
+where valid methods with corresponding keys are:
.TP
.B LABEL
device label or serial number, like USB serial number, SCSI UUID or
calling external program, that returns a string to match
.br
keys: \fBBUS\fP, \fBPROGRAM\fP, \fBID\fP
-.SH "EXAMPLE"
+.P
+The name field supports simple printf-like string subtitution:
+.RS
+.TP
+.B %n
+the "kernel number" of the device
+for example, 'sda3' has a "kernel number" of '3'
+.TP
+.B %M
+the kernel major number for the device
+.TP
+.B %m
+the kernel minor number for the device
+.TP
+.B %b
+the bus id for the device
+.RE
+.P
+A sample \fIudev.conf\fP might look like this:
+.sp
.nf
# USB printer to be called lp_color
LABEL, BUS="usb", serial="W09090207101241330", NAME="lp_color"
# ttyUSB1 should always be called pda
REPLACE, KERNEL="ttyUSB1", NAME="pda"
-# if /sbin/dev_id returns "V0815" device will be called dev0815
-CALLOUT, PROGRAM="/sbin/dev_id", BUS="pci", ID="V0815", NAME="dev0815"
+# if /sbin/scsi_id returns "OEM 0815" device will be called disk1
+CALLOUT, PROGRAM="/sbin/scsi_id" BUS="scsi", ID="OEM 0815" NAME="disk1"
+
+# USB webcams to be called webcam0, webcam1, ...
+LABEL, BUS="usb", model="WebCam Version 3", NAME="webcam%n"
.fi
+.P
+Permissions and ownership for the created device files may specified at
+.I /etc/udev/udev.permissions.
+The file consists of a set of lines. All empty lines and
+lines beginning with a '#' will be ignored.
+.br
+Every line lists a device name followed by owner, group and permission mode. All values are separated by colons.
+.sp
+A sample \fIudev.permissions\fP might look like this:
+.sp
+.nf
+#name:user:group:mode
+ttyUSB1:root:uucp:0666
+dsp1:::0666
+.fi
+
.SH "FILES"
.nf
.ft B
.fi
.LP
.SH "SEE ALSO"
-.B hotplug (8)
+.BR hotplug (8)
.PP
The
.I http://linux-hotplug.sourceforge.net/
web site.
.SH AUTHORS
-udev was developed by Greg Kroah-Hartman <greg@kroah.com> with much help from
+.B udev
+was developed by Greg Kroah-Hartman <greg@kroah.com> with much help from
Dan Stekloff <dsteklof@us.ibm.com> and many others.