<li>Testing and debugging
<ul>
<li><a href="#testing">Putting your rules into action</a></li>
- <li><a href="#udevtest">udevtest</a></li>
+ <li><a href="#udevtest">udevadm test</a></li>
</ul>
</li>
<li><a href="#author">Author and contact</a></li>
<h3>Rule files and semantics</h3>
<p>
-When deciding how to name a device and which additional actions to perform, udev reads a series of rules files. These files are kept in the <em>/etc/udev/rules.d</em> directory, and they all must have the <em>.rules</em> suffix.
+When deciding how to name a device and which additional actions to perform, udev reads a series of rules files. These files are kept in the <em>/etc/udev/rules.d</em> and <em>/lib/udev/rules.d</em> directories, and they all must have the <em>.rules</em> suffix. If two files with the same name exist in both directories then only the one in <em>/etc</em> is used.
</p>
<p>
-Default udev rules are stored in <em>/etc/udev/rules.d/50-udev.rules</em>. You may find it interesting to look over this file - it includes a few examples, and then some default rules proving a devfs-style /dev layout. However, you should not write rules into this file directly.
-</p>
-
-<p>
-Files in /etc/udev/rules.d/ are parsed in <b>lexical</b> order, and in some circumstances, the order in which rules are parsed is important. In general, you want your own rules to be parsed before the defaults, so I suggest you create a file at <em>/etc/udev/rules.d/10-local.rules</em> and write all your rules into this file.
+Files in the <em>rules.d</em> directories are parsed in <b>lexical</b> order, and in some circumstances, the order in which rules are parsed is important. In general, you want your own rules to be parsed before the defaults, so I suggest you create a file at <em>/etc/udev/rules.d/10-local.rules</em> and write all your rules into this file.
</p>
<p>
</p>
<p>
-To make the symbolic link show up, you can either disconnect and reconnect your camera, or alternatively in the case of non-removable devices, you can run <b>udevtrigger</b>.
-</p>
-
-<p>
-If your kernel does not have inotify support, new rules will not be detected automatically. In this situation, you must run <b>udevcontrol reload_rules</b> after making any rule file modifications for those modifications to take effect.
+To make the symbolic link show up, you can either disconnect and reconnect your camera, or alternatively in the case of non-removable devices, you can run <b>udevadm trigger</b>.
</p>
<a name="udevtest"></a>
-<h3>udevtest</h3>
+<h3>udevadm test</h3>
<p>
-If you know the top-level device path in sysfs, you can use <b>udevtest</b> to show the actions which udev would take. This may help you debug your rules. For example, assuming you want to debug a rule which acts on <em>/sys/class/sound/dsp</em>:
+If you know the top-level device path in sysfs, you can use <b>udevadm test</b> to show the actions which udev would take. This may help you debug your rules. For example, assuming you want to debug a rule which acts on <em>/sys/class/sound/dsp</em>:
</p>
<blockquote><pre>
-# udevtest /class/sound/dsp
+# udevadm test /class/sound/dsp
main: looking at device '/class/sound/dsp' from subsystem 'sound'
udev_rules_get_name: add symlink 'dsp'
udev_rules_get_name: rule applied, 'dsp' becomes 'sound/dsp'
</pre></blockquote>
<p>
-Note the <em>/sys</em> prefix was removed from the udevtest command line argument, this is because udevtest operates on device paths. Also note that udevtest is purely a testing/debugging tool, it does not create any device nodes, despite what the output suggests!
+Note the <em>/sys</em> prefix was removed from the udevadm test test command line argument, this is because udevadm test operates on device paths.
</p>
<a name="author"></a>