mirror of
https://git.linuxfromscratch.org/lfs.git
synced 2025-03-05 22:04:48 +00:00
Remove a lot of redundant Udev rules. Upstream has most of what we need. Fixes #2527.
git-svn-id: http://svn.linuxfromscratch.org/LFS/trunk/BOOK@9165 4aa44e1e-78dd-0310-a6d2-fbcd4c07a689
This commit is contained in:
Matthew Burgess
parent
cf8d1947c2
commit
3cf57d4059
@ -3,7 +3,6 @@
|
||||
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
|
||||
<!ENTITY % general-entities SYSTEM "../general.ent">
|
||||
<!ENTITY lfs-rules SYSTEM "55-lfs.rules.script">
|
||||
<!ENTITY cdrom-rules SYSTEM "61-cdrom.rules.script">
|
||||
%general-entities;
|
||||
]>
|
||||
|
||||
@ -22,9 +21,4 @@
|
||||
<screen>&lfs-rules;</screen>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="cdromrules" role="wrap">
|
||||
<title>61-cdrom.rules</title>
|
||||
<screen>&cdrom-rules;</screen>
|
||||
</sect1>
|
||||
|
||||
</appendix>
|
||||
|
||||
@ -37,6 +37,17 @@
|
||||
|
||||
-->
|
||||
|
||||
<listitem>
|
||||
<para>2010-01-24</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>[matthew] Remove a lot of redundant Udev rules, using upstream's
|
||||
rules instead. Fixes
|
||||
<ulink url="&lfs-ticket-root;2527">#2527</ulink>.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>2010-01-24</para>
|
||||
<itemizedlist>
|
||||
|
||||
@ -57,6 +57,10 @@ ln -sv /proc/self/fd/1 /lib/udev/devices/stdout
|
||||
ln -sv /proc/self/fd/2 /lib/udev/devices/stderr
|
||||
ln -sv /proc/kcore /lib/udev/devices/core</userinput></screen>
|
||||
|
||||
<para>Correct permissions for floppy devices:</para>
|
||||
|
||||
<screen><userinput remap="pre">sed -e 's/0640/0660/' extras/floppy/60-floppy.rules</userinput></screen>
|
||||
|
||||
<para>Prepare the package for compilation:</para>
|
||||
|
||||
<!-- Note that "libdir=/usr/lib64" would be required for multilib. -->
|
||||
|
||||
@ -508,7 +508,7 @@
|
||||
<!ENTITY udev-ch6-du "11.6 MB">
|
||||
<!ENTITY udev-ch6-sbu "0.2 SBU">
|
||||
|
||||
<!ENTITY udev-config "udev-config-20090925"> <!-- Scripts depend on this format -->
|
||||
<!ENTITY udev-config "udev-config-20100126"> <!-- Scripts depend on this format -->
|
||||
<!ENTITY udev-config-size "UDEV-SIZE KB"> <!-- Updated in Makefile -->
|
||||
<!ENTITY udev-config-url "&downloads-root;&udev-config;.tar.bz2">
|
||||
<!ENTITY udev-config-md5 "UDEV-MD5SUM"> <!-- Updated in Makefile -->
|
||||
|
||||
@ -12,51 +12,3 @@ KERNEL=="ippp[0-9]*", GROUP="dialout"
|
||||
KERNEL=="isdn[0-9]*", GROUP="dialout"
|
||||
KERNEL=="isdnctrl[0-9]*", GROUP="dialout"
|
||||
KERNEL=="dcbri[0-9]*", GROUP="dialout"
|
||||
|
||||
# ALSA devices go in their own subdirectory
|
||||
|
||||
KERNEL=="controlC[0-9]*", GROUP="audio", NAME="snd/%k"
|
||||
KERNEL=="hwC[0-9]*D[0-9]*", GROUP="audio", NAME="snd/%k"
|
||||
KERNEL=="pcmC[0-9]*D[0-9]*[cp]", GROUP="audio", NAME="snd/%k"
|
||||
KERNEL=="midiC[0-9]*D[0-9]*", GROUP="audio", NAME="snd/%k"
|
||||
KERNEL=="timer", GROUP="audio", NAME="snd/%k"
|
||||
KERNEL=="seq", GROUP="audio", NAME="snd/%k"
|
||||
|
||||
# Sound devices
|
||||
|
||||
KERNEL=="admmidi*", GROUP="audio"
|
||||
KERNEL=="adsp*", GROUP="audio"
|
||||
KERNEL=="aload*", GROUP="audio"
|
||||
KERNEL=="amidi*", GROUP="audio"
|
||||
KERNEL=="amixer*", GROUP="audio"
|
||||
KERNEL=="audio*", GROUP="audio"
|
||||
KERNEL=="dmfm*", GROUP="audio"
|
||||
KERNEL=="dmmidi*", GROUP="audio"
|
||||
KERNEL=="dsp*", GROUP="audio"
|
||||
KERNEL=="midi*", GROUP="audio"
|
||||
KERNEL=="mixer*", GROUP="audio"
|
||||
KERNEL=="music", GROUP="audio"
|
||||
KERNEL=="sequencer*", GROUP="audio"
|
||||
|
||||
# Input devices
|
||||
|
||||
KERNEL=="mice", SYMLINK+="mouse"
|
||||
|
||||
# DRI devices are managed by the X server, so prevent udev from creating them
|
||||
|
||||
KERNEL=="card*", OPTIONS+="ignore_device"
|
||||
|
||||
# Video devices
|
||||
|
||||
KERNEL=="fb[0-9]*", GROUP="video"
|
||||
|
||||
# Storage/memory devices
|
||||
|
||||
# dmsetup and lvm2 related programs create devicemapper devices so we prevent
|
||||
# udev from creating them
|
||||
|
||||
KERNEL=="dm-*", OPTIONS+="ignore_device"
|
||||
|
||||
# Override floppy devices
|
||||
KERNEL=="fd[0-9]", ACTION=="add|change", ATTRS{cmos}=="?*", \
|
||||
RUN+="create_floppy_devices -c -t $attr{cmos} -m %M -M 0660 -G floppy $root/%k"
|
||||
|
||||
@ -1,3 +0,0 @@
|
||||
# /etc/udev/rules.d/61-cdrom.rules: Set CD-ROM permissions.
|
||||
|
||||
ACTION=="add|change", SUBSYSTEM=="block", ENV{ID_TYPE}=="cd", GROUP="cdrom"
|
||||
@ -1,3 +1,8 @@
|
||||
2010-01-26 Matt Burgess <matthew@linuxfromscratch.org>
|
||||
* 55-lfs.rules: Remove lots of rules that have been merged upstream.
|
||||
* 61-cdrom.rules: Remove as upstream has a replacement.
|
||||
* doc/*: Cleanup and rewrite now that the rules are much simpler.
|
||||
|
||||
2009-09-25 Bryan Kadzban <bryan@linuxfromscratch.org>
|
||||
* 55-lfs.rules: Make the RTC rule (which runs setclock) work for people
|
||||
that don't use the RTC-class driver -- add another copy of the rule,
|
||||
|
||||
@ -5,8 +5,7 @@ RULES_DIR = /etc/udev/rules.d
|
||||
INSTALL = install
|
||||
INSTALL_DATA = $(INSTALL) -m644
|
||||
RULES_FILES = \
|
||||
55-lfs.rules \
|
||||
61-cdrom.rules
|
||||
55-lfs.rules
|
||||
DOC_FILES = $(RULES_FILES:.rules=.txt)
|
||||
|
||||
EXTRA_DOC_FILES = \
|
||||
|
||||
@ -1,33 +0,0 @@
|
||||
Purpose of rules file:
|
||||
|
||||
The kernel does not always fully populate a given kobject's attributes before
|
||||
sending the uevent for that kobject. This means that a given sysfs directory
|
||||
may not have all the required files in it (each directory corresponds to a
|
||||
kobject, and each file corresponds to an attribute).
|
||||
|
||||
Therefore, we must sometimes wait for attributes to show up when devices are
|
||||
discovered. This is accomplished by udev's WAIT_FOR_SYSFS rule types.
|
||||
|
||||
|
||||
Description of rules:
|
||||
|
||||
All rules in this file match ACTION="add", because none of them apply when
|
||||
devices are being removed.
|
||||
|
||||
SUBSYSTEM is the kernel subsystem that the device uses. Current kernels have
|
||||
some issues with SCSI device attributes being created too late. For any device
|
||||
with a SUBSYSTEM of scsi, we must wait for the ioerr_cnt attribute. (This is
|
||||
the last attribute created for SCSI devices, so when this attribute appears,
|
||||
the kobject is fully populated.)
|
||||
|
||||
It is also possible to use SUBSYSTEMS in Udev rules. Using SUBSYSTEMS would
|
||||
cause Udev to search up the device tree for a matching SUBSYSTEM value. (Note
|
||||
that "the device tree" is not necessarily the same as the path under /sys (the
|
||||
DEVPATH). Rather, "up the device tree" is the path followed by udevinfo when
|
||||
it is given the argument "-a".)
|
||||
|
||||
We do not use SUBSYSTEMS in this rule, because we only care about the SUBSYSTEM
|
||||
of the kobject in question. We don't care about devices that are children of
|
||||
SCSI devices, only the SCSI device itself. We will use SUBSYSTEMS in later
|
||||
rules, though.
|
||||
|
||||
@ -1,94 +1,20 @@
|
||||
Purpose of rules file:
|
||||
|
||||
This is the core rules file for Udev on LFS. If these rules were not included,
|
||||
most devices would either only work for root, or would not work at all.
|
||||
|
||||
Most of the rules installed by Udev itself create devices with the correct
|
||||
properties. This file contains rules that have not been merged upstream yet.
|
||||
|
||||
Description of rules:
|
||||
|
||||
By default, Udev creates device nodes with UID 0, GID 0, and permissions 0660,
|
||||
and in one flat directory structure with all nodes in /dev. This does not
|
||||
always work well.
|
||||
By default, Udev creates device nodes with UID 0, GID 0, and permissions 0660.
|
||||
|
||||
KERNEL=="ptmx"
|
||||
ISDN-related devices should be owned by the 'dialout' group, hence the following
|
||||
rule (and similar):
|
||||
|
||||
Any uevent generated by the kernel with a name matching "ptmx" will match this
|
||||
rule. Note that the matching done by Udev is shell-style; these are not regex
|
||||
matches. For the ptmx device, we first change the permisions, by assigning to
|
||||
the MODE value:
|
||||
|
||||
KERNEL=="ptmx", MODE="0666"
|
||||
|
||||
We also assign a different GID to /dev/ptmx (also all other TTY devices), by
|
||||
assigning to the GROUP value:
|
||||
|
||||
KERNEL=="ptmx", MODE="0666", "GROUP="tty"
|
||||
|
||||
|
||||
There are also devices that should not be in /dev, because historically they
|
||||
have been created in subdirectories instead. For instance, all Alsa devices
|
||||
have traditionally been put into the /dev/snd subdirectory:
|
||||
|
||||
KERNEL=="controlC[0-9]*", <...>, NAME="snd/%k"
|
||||
|
||||
"%k" expands into "the original value of KERNEL" (note: not the pattern that was
|
||||
matched against). This type of rule puts any matching device into the snd/
|
||||
subdirectory.
|
||||
|
||||
Sometimes we need to move devices based on more than just their name. For
|
||||
example, USB printer devices need to be moved to /dev/usb/lpX, but we can't
|
||||
match only "lp[0-9]*", because that would also match parallel port printers.
|
||||
So we match both KERNEL and SUBSYSTEMS in this case, to move USB printers only.
|
||||
|
||||
|
||||
Some devices also commonly have symlinks pointing to them -- for example,
|
||||
/dev/mouse is usually a symlink to /dev/input/mice. We acheive this by
|
||||
assigning to the SYMLINK value. But note that SYMLINK can store multiple values
|
||||
(because each device node could have multiple symlinks pointing to it), so we
|
||||
need to add to the list of symlinks, not overwrite the whole list:
|
||||
|
||||
KERNEL=="mice", <...>, SYMLINK+="mouse"
|
||||
|
||||
If we needed to add multiple symlinks, they would be space-separated inside the
|
||||
double quotes.
|
||||
|
||||
Of course, symlinks, permissions, and device names can all be combined in a
|
||||
rule if needed. But note that if you combine permissions and symlinks, or if
|
||||
you combine GROUP and symlinks, the permissions of the symlink will not be
|
||||
modified, only those of the target device. (This is because the kernel does
|
||||
not pay any attention to the permissions on symlinks, only the permissions on
|
||||
their targets, and there's no reason to change something that won't be used.)
|
||||
|
||||
|
||||
Finally, we have this rule:
|
||||
|
||||
SUBSYSTEM=="usb_device", PROGRAM="/bin/sh -c 'X=%k; X=$${X#usbdev}; B=$${X%%%%.*} D=$${X#*.}; echo bus/usb/$$B/$$D'", NAME="%c"
|
||||
|
||||
This rule matches any device under the SUBSYSTEM of usb_device. (All devices
|
||||
that were traditionally created under /proc/bus/usb/ use this subsystem.) We
|
||||
tell Udev to run the specified PROGRAM; Udev will save the output of this
|
||||
program (it will be available under %c later).
|
||||
|
||||
The program itself is a shell that starts by setting the variable X to the
|
||||
original kernel name (which is "usbdevB.D" for these devices, where B and D are
|
||||
the bus and device numbers of the USB device). Then, the rule re-sets X to the
|
||||
value of X with the string "usbdev" removed from the start. So now, X has the
|
||||
value "B.D". Then, the rule sets B to the value of X after a period, and all
|
||||
characters following it, have been removed from the end; this sets B to just
|
||||
the string "B" (just the bus number of the USB device). Then, the rule sets D
|
||||
to the value of X after a period, and all characters before it, have been
|
||||
removed from the beginning; this sets D to just the string "D" (just the device
|
||||
number).
|
||||
|
||||
Then, the rule echoes "bus/usb/$B/$D" (bus/usb/bus-number/device-number), so
|
||||
Udev will capture that value. The rule sets NAME="%c" to put the device node
|
||||
at /dev/bus/usb/bus-number/device-number. (This is the same layout that the
|
||||
/proc/bus/usb/ devices used.)
|
||||
|
||||
Most of the doubled characters in this rule are doubled so that Udev does not
|
||||
interpret them. The rule looks all the more confusing because of this method
|
||||
of escaping special characters.
|
||||
KERNEL=="ippp[0-9]*", GROUP="dialout"
|
||||
|
||||
The RTC-related rules cause the setclock bootscript to be run as soon as the
|
||||
RTC device has been created by Udev, meaning that times in log files, for
|
||||
example, are as accurate as possible as quickly as possible.
|
||||
|
||||
A final word of caution: Any particular rule must be written on one line, and a
|
||||
comma must separate each part of the rule.
|
||||
|
||||
@ -1,86 +0,0 @@
|
||||
Purpose of rules file:
|
||||
|
||||
This rules file provides nonvolatile, unique names (in the form of symlinks)
|
||||
for input devices that cooperate.
|
||||
|
||||
|
||||
Description of rules:
|
||||
|
||||
This file starts off with a few rules that make Udev skip the entire file if
|
||||
the current uevent is not input related. If ACTION is not "add", or SUBSYSTEM
|
||||
is not "input", or KERNEL (the device node) matches "input[0-9]*", then Udev
|
||||
will GOTO the LABEL named "persistent_input_end", which is the last rule in
|
||||
this file. (input[0-9]* uevents are skipped because they do not create device
|
||||
nodes.)
|
||||
|
||||
This type of "skip this list of rules if X" operation is done in both the
|
||||
persistent input and persistent storage rules files. The reason is efficiency
|
||||
-- if Udev had to go run the usb_id and/or path_id programs for non-input and
|
||||
non-storage rules, those rules would take much longer to process for no good
|
||||
reason.
|
||||
|
||||
|
||||
First in this file is a set of rules for by-ID style symlinks. These attempt
|
||||
to uniquely identify a device based on its serial number, but there are some
|
||||
issues with this. Many USB manufacturers do not provide a unique serial number
|
||||
for each device -- for instance, my Microsoft Intellimouse Optical has a USB
|
||||
serial number of "Microsoft_Microsoft_IntelliMouse_Optical". This kind of
|
||||
nonsensical "serial number" means that if you plug in two Intellimouse Optical
|
||||
devices, they will both get the same by-id symlink, and the device that the
|
||||
symlink points to will be random. This defeats the purpose of by-ID symlinks.
|
||||
(However, I believe this behavior is technically valid according to the USB
|
||||
standard. I believe it is not recommended, though.)
|
||||
|
||||
Anyway, first in the by-ID rules, we have a rule that runs for any (input)
|
||||
device hanging anywhere off a USB bus. It uses the IMPORT{program} option to
|
||||
run the "/lib/udev/usb_id -x" program. usb_id looks at the environment to find
|
||||
out which device to look at, generates a list of environment-variable VAR=value
|
||||
pairs, and prints them. Udev stores this output away while the process is
|
||||
running. After the process exits, Udev modifies the current environment to
|
||||
include the VARs that usb_id printed. (It assigns the "value"s that usb_id
|
||||
printed to each of those VARs.) Specifically, usb_id prints ID_VENDOR,
|
||||
ID_MODEL, ID_REVISION, ID_SERIAL, ID_TYPE, and ID_BUS (at least in the case of
|
||||
the aforementioned USB optical mouse). These variable names will all be set in
|
||||
the environment.
|
||||
|
||||
Then, we have a set of rules to set ID_CLASS for various types of devices. The
|
||||
rules first check for a "usb"-bus device that has a "bInterfaceClass" of 03 and
|
||||
a "bInterfaceProtocol" of 01. If the interface class is 03, this is an HID
|
||||
device. If the protocol is 01, it's a keyboard device. So we set ID_CLASS to
|
||||
"kbd". The next rule checks whether the interface protocol is 02, and if so,
|
||||
sets ID_CLASS to "mouse" (HID devices with a protocol of 02 are mice).
|
||||
|
||||
Any input device that the "pcspkr" driver claims must be a speaker. Any input
|
||||
device that the "atkbd" driver claims must be a keyboard. Any input device
|
||||
that the "psmouse" driver claims must be a mouse. If there's a sysfs attribute
|
||||
named "name", whose contents contain "dvb", "DVB", or " IR ", then we set
|
||||
ID_CLASS to "ir".
|
||||
|
||||
Then, we have a rule to search the tree and find the first parent that has a
|
||||
modalias. If that modalias matches the big long ugly string in the rules file,
|
||||
we assume this is a joystick device, and set ID_CLASS appropriately. (This
|
||||
parent should be the kobject for the joystick device itself. The reason we
|
||||
search the tree is that the current uevent is for a device node, not the
|
||||
physical joystick device.)
|
||||
|
||||
Once the ID_CLASS variable is set properly, we have one more modification to
|
||||
perform: if the ID_SERIAL variable was not set at all by the usb_id program, we
|
||||
set it to "noserial".
|
||||
|
||||
Now that all the environment variables are set up properly, we start generating
|
||||
the by-ID symlinks in /dev/input/by-id/. If the current device node's name
|
||||
starts with "event", we add "event" into the symlink name. Otherwise, we don't
|
||||
add anything for mice. (Other device types don't get a persistent by-ID
|
||||
symlink.)
|
||||
|
||||
|
||||
Next, we create by-path symlinks. The /lib/udev/path_id program takes the path
|
||||
of the device as an argument, and prints out "ID_PATH=string", where "string"
|
||||
is the "shortest physical path" to the device. We import this value into the
|
||||
environment.
|
||||
|
||||
If the path is non-empty, and the device node name starts with "mouse" or
|
||||
"event", we add a by-path symlink based on the path and the device class (and
|
||||
we also add "event" if it's an event device). This symlink should be stable as
|
||||
long as the device never moves to a different port.
|
||||
|
||||
@ -1,95 +0,0 @@
|
||||
Purpose of rules file:
|
||||
|
||||
This rules file provides nonvolatile, unique names (in the form of symlinks)
|
||||
for various types of storage devices -- both IDE/ATA and SCSI.
|
||||
|
||||
|
||||
Description of rules:
|
||||
|
||||
First, similar to the 60-persistent-input.rules file, we skip the entire file
|
||||
for uevents that this rules file should not apply to, as an optimization. The
|
||||
file does not apply to removal uevents or non-block devices. It does not apply
|
||||
to ramdisks, loopback-mount devices, floppy disks, netblock devices, or device-
|
||||
mapper devices. It also should not apply to removable devices (that is, non-
|
||||
partition devices with attributes named "removable" with the value "1", or
|
||||
partition devices whose parents have "removable" set to "1" -- partition
|
||||
kobjects don't have the "removable" attribute, only whole-disk kobjects do).
|
||||
|
||||
For partition devices, we use the IMPORT{parent} option to pull in all the
|
||||
environment variables that get set for the parent device. (The parent of a
|
||||
partition device is the containing whole-disk device.) The IMPORT{parent}
|
||||
option is documented in the udev(7) manpage, but basically the value that we
|
||||
assign is used as a filter of environment variable names to import.
|
||||
|
||||
Now, we start with rules to create by-ID symlinks (similar to the by-ID links
|
||||
created for input devices). For hd* whole-disk devices (they're IDE/ATA, since
|
||||
they start with hd), we run the ata_id program in --export mode. The ata_id
|
||||
program requires a device node to be passed, so we also use the $tempnode Udev
|
||||
variable -- this causes Udev to create a temporary device node somewhere and
|
||||
substitute its name where $tempnode appears in the program command line.
|
||||
|
||||
The ata_id program, in --export mode, prints several ID_* values. If we're
|
||||
looking at a whole-disk device, and if ID_SERIAL is among those, we add a
|
||||
symlink containing the device's ID_MODEL and ID_SERIAL values. If we're
|
||||
looking at a partition device, we create an ID_MODEL- and ID_SERIAL-based
|
||||
symlink also, but we add -partX to the end of the link name (where X is the
|
||||
partition number).
|
||||
|
||||
For SCSI devices, we first make some modifications to the environment. If the
|
||||
device's kobject has a parent with a non-empty "ieee1394_id" attribute, then
|
||||
the device is Firewire, so we set the ID_SERIAL environment variable to the
|
||||
value of that attribute, and we set ID_BUS to "ieee1394". Now, if ID_SERIAL is
|
||||
not set, we run usb_id, which (if this is a USB storage device) will print
|
||||
various values. If ID_SERIAL is still unset, we run scsi_id with a set of
|
||||
parameters designed to get an ID_SERIAL by querying the device itself. If that
|
||||
still fails, we try running scsi_id in a mode that prints the information even
|
||||
if the disk doesn't support so-called "vital product data" pages. If the
|
||||
uevent is for a DASD device, we run dasd_id.
|
||||
|
||||
If one of these *_id programs gave us an ID_SERIAL, then for whole-disk devices
|
||||
we create a by-ID symlink using the ID_BUS and ID_SERIAL. For partition
|
||||
devices, we create a by-ID symlink that has the same form except we add -partX
|
||||
to the end (just like for IDE/ATA devices).
|
||||
|
||||
|
||||
Now we have some rules to create by-path persistent symlinks. We start by
|
||||
running the path_id program on the DEVPATH (%p) value. For whole-disk devices
|
||||
and SCSI ROM type devices, we create a symlink directly, using the environment
|
||||
variable ID_PATH, under the /dev/disk/by-path directory. But for SCSI tape
|
||||
devices, we create a by-path symlink in the /dev/tape/by-path directory (we
|
||||
base the symlink on the same information, though: the ID_PATH value printed by
|
||||
path_id). Now, for both SCSI ROM and SCSI tape devices, we skip everything
|
||||
that's left in the rules file (this is another optimization: neither SCSI ROM
|
||||
nor SCSI tape devices have UUIDs, labels, or EDD information).
|
||||
|
||||
For partition devices, we now create a by-path symlink of the same form as the
|
||||
other partition device persistent symlinks (that is, with the same name as the
|
||||
parent device, but with -partX added). We know that ID_PATH is set whenever it
|
||||
applies, because we ran the path_id program on the parent device, and we did an
|
||||
IMPORT{parent} on ID_* earlier in the rules file.
|
||||
|
||||
Now we create by-label and by-uuid symlinks. These use properties of various
|
||||
filesystems to generate a persistent name for a partition. For instance, if
|
||||
you use the ext2 filesystem, you can use e2label to assign a label, and mke2fs
|
||||
assigns a UUID when the filesystem is created. MS-DOS compatible filesystems
|
||||
also assign a "UUID" (actually it's just a serial number, created based on the
|
||||
date and time the partition was formatted, so it is not unique), which these
|
||||
rules will also use. But for removable partitions, we skip the rules (for the
|
||||
same reason as we skipped them above for removable disks).
|
||||
|
||||
We run the vol_id program to get ID_FS_USAGE, ID_FS_UUID, and ID_FS_LABEL_SAFE
|
||||
values. (vol_id supports other values as well, but we do not use them here.)
|
||||
ID_FS_USAGE corresponds to the way the filesystem is supposed to be used; if it
|
||||
gets set to "filesystem", "other", or "crypto", we create a symlink. If
|
||||
ID_FS_UUID is set, we use it in a by-uuid symlink. If ID_FS_LABEL_SAFE is set,
|
||||
we use it in a by-label symlink.
|
||||
|
||||
Finally, we create EDD-based symlinks in the by-id directory. For whole-disk
|
||||
devices, we run edd_id to get the EDD-generated ID string. (For partition
|
||||
devices, we import this string from the parent.) If edd_id yields an ID_EDD
|
||||
value, we use it in a symlink, for both whole disks and partitions.
|
||||
|
||||
|
||||
The last rule in the file is merely a LABEL that various other rules use to
|
||||
bypass the file (or the rest of the file) when needed.
|
||||
|
||||
@ -1,16 +0,0 @@
|
||||
Purpose of rules file:
|
||||
|
||||
This file re-assigns CD-ROM type devices to the "cdrom" group.
|
||||
|
||||
|
||||
Description of rules:
|
||||
|
||||
There is only one rule here. It depends on the 60-persistent-storage file,
|
||||
though, because it requires the ID_TYPE environment variable to be set properly
|
||||
for CD devices. Normally the rules in the 60-persistent-storage.rules file
|
||||
will run the correct *_id programs to do this properly.
|
||||
|
||||
If ID_TYPE is "cd", and this is a block device, and it's an add event, then we
|
||||
assign the device to the "cdrom" group. Simple, once the *_id programs have
|
||||
all been run.
|
||||
|
||||
@ -1,69 +0,0 @@
|
||||
Purpose of rules file:
|
||||
|
||||
The rules in this file allow Udev to fully replace the old /sbin/hotplug
|
||||
script. They automatically load kernel modules as devices are discovered.
|
||||
|
||||
|
||||
Description of rules:
|
||||
|
||||
All rules in this file match ACTION=="add", so they only run when devices are
|
||||
being added.
|
||||
|
||||
ENV{MODALIAS} is the value of the environment variable named MODALIAS. This
|
||||
environment variable is sent by the kernel when it sends a uevent for any
|
||||
device that has a modalias. Modaliases are strings that can be used to load
|
||||
the appropriate kernel module driver.
|
||||
|
||||
Generally a modalias will contain information like vendor ID, device ID, and
|
||||
possibly other IDs depending on the bus the device is connected to. (USB, for
|
||||
instance, has the concept of a "device class" and a "device interface", which
|
||||
are basically just ways to standardize the USB protocol for various types of
|
||||
devices. This is what allows a single kernel module such as hid.ko to drive
|
||||
many different vendors' USB input devices: all devices that support the USB
|
||||
HID interface expose the HID interface number in their modalias, and so the
|
||||
hid.ko driver can be loaded for each device. When it loads, hid.ko attaches
|
||||
to the HID interface and does whatever is needed to work with each device.)
|
||||
|
||||
Kernel modules that drive hardware expose a list of modaliases. These
|
||||
modaliases are matched against the device modalias by /sbin/modprobe (after
|
||||
shell-style expansion), with the help of /sbin/depmod's modules.alias file.
|
||||
The upshot of all this is, you can tell Udev to run "/sbin/modprobe modalias",
|
||||
and it will load the module that claims it can drive the "modalias" device.
|
||||
|
||||
The rule that does this inspects ENV{MODALIAS} to ensure it is not empty. It
|
||||
does this by comparing it to "?*" -- inside a match, "*" would match *any*
|
||||
string, including the empty string, so to ensure MODALIAS is not empty, we need
|
||||
to match against "?*" instead. ("?" matches any one character.)
|
||||
|
||||
The Udev RUN+="" option adds a program to run when the rule matches. In this
|
||||
case, we tell Udev to run "/sbin/modprobe $env{MODALIAS}". Note that Udev does
|
||||
not do path searches; if the executable is not specified with a fully-qualified
|
||||
path, it *must* be located under the /lib/udev directory. If it is not, you
|
||||
*must* specify a fully-qualified path, as we do here. Also, "$env{string}" is
|
||||
replaced by the value of the environment variable "string" when the command
|
||||
runs, so this adds the modalias to the modprobe command. The modprobe program
|
||||
will do the rest. Finally, the {ignore_error} option is added to the RUN key;
|
||||
this prevents Udev from failing the uevent if the modprobe command fails. (The
|
||||
modprobe command will fail when run during cold-plugging, if the driver was
|
||||
configured into the kernel instead of as a module, for instance.)
|
||||
|
||||
There is still one feature of the old hotplug shell-script system that Udev
|
||||
cannot provide: blacklisting modules from being auto-loaded. To accomplish
|
||||
this, we must use module-init-tools. In /etc/modprobe.conf, if you use the
|
||||
"blacklist <module-name>" syntax, modprobe will not load <module-name> under
|
||||
any name except its real module name. Any modaliases exposed by that module
|
||||
will not be honored.
|
||||
|
||||
|
||||
There are also rules in this file for various other types of driver loading.
|
||||
PNP-BIOS devices, for instance, expose a list of PNP IDs in their sysfs "id"
|
||||
attribute, instead of exposing a single MODALIAS, so one rule loops through
|
||||
each ID and tries to load the appropriate module. Several other types of
|
||||
devices require an extra module before they will work properly; one example
|
||||
of this is IDE tapes, which require the ide-scsi module. Finally, whenever
|
||||
any SCSI device is found, the file uses the TEST key to check whether the
|
||||
/sys/module/sg directory exists. If not, then the "sg" module -- the SCSI
|
||||
generic driver -- is loaded. (That driver creates the module/sg directory,
|
||||
so the module/sg test is just to see whether the driver has already been
|
||||
loaded.)
|
||||
|
||||
@ -1,18 +0,0 @@
|
||||
Purpose of rules file:
|
||||
|
||||
Sends all uevents to a Unix-domain socket, where they can be monitored by other
|
||||
programs.
|
||||
|
||||
|
||||
Description of rules:
|
||||
|
||||
There is only one rule, which matches all uevents. It uses Udev's RUN key to
|
||||
specify a socket to send each uevent to. Normally RUN is used to start up a
|
||||
process, but if the pathname starts with "socket:", Udev instead interprets
|
||||
the rest of the name as a Unix-domain socket to send the uevent to. In this
|
||||
case, we send send the uevent to the socket named /org/kernel/udev/monitor,
|
||||
which is created by the udevmonitor program. Udevmonitor is used to watch
|
||||
uevents as they come to Udev. Its only purpose is for debugging, but sending
|
||||
the uevent to a socket that doesn't exist is a very cheap operation, so we
|
||||
enable this rule for all uevents.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user