default rules directory <filename>/lib/udev/rules.d/</filename>,
the custom rules directory <filename>/etc/udev/rules.d/</filename>
and the temporary rules directory <filename>/run/udev/rules.d/</filename>.
- All rule files are sorted and processed in lexical order, regardless
- in which of these directories they live. Files in
- <filename>/etc/udev/rules.d/</filename> have precedence over files with
- the same name in <filename>/lib/udev/rules.d/</filename>. This can be
+ All rule files are collectively sorted and processed in lexical order,
+ regardless of the directories in which they live. However, files in
+ <filename>/etc/udev/rules.d/</filename> take precedence over files with
+ the same name in <filename>/lib/udev/rules.d/</filename>; this can be
used to ignore a default rules file if needed.</para>
- <para>Rule files must end in <filename>.rules</filename>, other extensions
- are ignored.</para>
+ <para>Rule files must have the extension <filename>.rules</filename>; other
+ extensions are ignored.</para>
- <para>Every line in the rules file contains at least one key value pair.
- There are two kind of keys, match and assignment keys.
+ <para>Every line in the rules file contains at least one key-value pair.
+ There are two kind of keys: match and assignment.
If all match keys are matching against its value, the rule gets applied and the
- assign keys get the specified value assigned.</para>
+ assignment keys get the specified value assigned.</para>
<para>A matching rule may rename a network interface, add symlinks
pointing to the device node, or run a specified program as part of
the event handling.</para>
- <para>A rule consists of a list of one or more key value pairs separated by
- a comma. Each key has a distinct operation, depending on the used operator. Valid
+ <para>A rule consists of a comma-separated list of one or more key-value pairs.
+ Each key has a distinct operation, depending on the used operator. Valid
operators are:</para>
<variablelist>
<varlistentry>
<varlistentry>
<term><option>:=</option></term>
<listitem>
- <para>Assign a value to a key finally; disallow any later changes,
- which may be used to prevent changes by any later rules.</para>
+ <para>Assign a value to a key finally; disallow any later changes.</para>
</listitem>
</varlistentry>
</variablelist>
<varlistentry>
<term><option>DRIVER</option></term>
<listitem>
- <para>Match the driver name of the event device. Only set for devices
+ <para>Match the driver name of the event device. Only set this key for devices
which are bound to a driver at the time the event is generated.</para>
</listitem>
</varlistentry>
<term><option>ATTR{<replaceable>filename</replaceable>}</option></term>
<listitem>
<para>Match sysfs attribute values of the event device. Trailing
- whitespace in the attribute values is ignored, if the specified match
- value does not contain trailing whitespace itself.
+ whitespace in the attribute values is ignored unless the specified match
+ value itself contains trailing whitespace.
</para>
</listitem>
</varlistentry>
<listitem>
<para>Search the devpath upwards for a device with matching sysfs attribute values.
If multiple <option>ATTRS</option> matches are specified, all of them
- must match on the same device. Trailing whitespace in the attribute values is ignored,
- if the specified match value does not contain trailing whitespace itself.</para>
+ must match on the same device. Trailing whitespace in the attribute values is ignored
+ unless the specified match value itself contains trailing whitespace.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>PROGRAM</option></term>
<listitem>
- <para>Execute a program. The key is true, if the program returns
+ <para>Execute a program to determine whether there
+ is a match; the key is true if the program returns
successfully. The device properties are made available to the
- executed program in the environment. The program's output printed to
- stdout, is available in the RESULT key.</para>
+ executed program in the environment. The program's stdout
+ is available in the RESULT key.</para>
</listitem>
</varlistentry>
</varlistentry>
</variablelist>
- <para>Most of the fields support a shell style pattern matching. The following
+ <para>Most of the fields support shell-style pattern matching. The following
pattern characters are supported:</para>
<variablelist>
<varlistentry>
<term><option>*</option></term>
<listitem>
- <para>Matches zero, or any number of characters.</para>
+ <para>Matches zero or more characters.</para>
</listitem>
</varlistentry>
<varlistentry>
<listitem>
<para>Matches any single character specified within the brackets. For
example, the pattern string 'tty[SR]' would match either 'ttyS' or 'ttyR'.
- Ranges are also supported within this match with the '-' character.
- For example, to match on the range of all digits, the pattern [0-9] would
+ Ranges are also supported via the '-' character.
+ For example, to match on the range of all digits, the pattern [0-9] could
be used. If the first character following the '[' is a '!', any characters
not enclosed are matched.</para>
</listitem>
<varlistentry>
<term><option>NAME</option></term>
<listitem>
- <para>The name, a network interface should be renamed to. Or as
- a temporary workaround, the name a device node should be named.
- Usually the kernel provides the defined node name, or even creates
+ <para>What a network interface should be named.</para>
+ <para>Also, as a temporary workaround, this is what a device node
+ should be named; usually the kernel provides the defined node name or creates
and removes the node before udev even receives any event. Changing
the node name from the kernel's default creates inconsistencies
and is not supported. If the kernel and NAME specify different names,
- an error is logged. Udev is only expected to handle device node
+ an error is logged. udev is only expected to handle device node
permissions and to create additional symlinks, not to change
kernel-provided device node names. Instead of renaming a device node,
- SYMLINK should be used. Symlink names must never conflict with
- device node names, it results in unpredictable behavior.</para>
+ SYMLINK should be used. However, symlink names must never conflict with
+ device node names, as that would result in unpredictable behavior.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><option>watch</option></term>
<listitem>
- <para>Watch the device node with inotify, when closed after being opened for
+ <para>Watch the device node with inotify; when closed after being opened for
writing, a change uevent is synthesised.</para>
</listitem>
</varlistentry>
~ianmdlvl / elogind.git / blobdiff