<h1>Writing udev rules</h1>
by Daniel Drake (dsd)<br />
-Version 0.55<br /><br />
+Version 0.6<br /><br />
The most recent version of this document can always be found at: <br />
<a href="http://www.reactivated.net/udevrules.php">http://www.reactivated.net/udevrules.php</a>
<li><a href="#keys">Key-writing basics</a></li>
<li><a href="#identify-keys">Identifying devices through basic keys</a></li>
<li><a href="#identify-sysfs">Identifying devices through SYSFS files</a></li>
+<li><a href="#multiple-symlinks">Using multiple SYMLINK style rules</a></li>
+<li><a href="#mode-owner-group">Controlling ownership and permissions</a></li>
<li><a href="#example-printer">Example: Writing a rule for my USB printer</a></li>
<li><a href="#example-camera">Example: Writing a rule for my USB-Storage digital camera</a></li>
<li><a href="#example-cdrom">Example: Writing convenience rules for my CD drives</a></li>
<li><a href="#example-iface">Example: Writing a rule to name my network interface</a></li>
<li><a href="#tips">Tips for finding the appropriate places in SYSFS</a></li>
-<li><a href="#multiple-symlinks">Using multiple SYMLINK style rules</a></li>
-<li><a href="#nvidia">udev vs Nvidia's graphics drivers</a></li>
+<li><a href="#debugging">Debugging your rules</a></li>
<li><a href="#author">Author and credits</a></li>
</ol>
<h2>History</h2>
+May 9th 2005 v0.6: Misc updates, including information about udevinfo, groups and permissions, logging, and udevtest.<br /><br />
June 20th 2004 v0.55: Added info on multiple symlinks, and some minor changes/updates.<br /><br />
April 26th 2004 v0.54: Added some Debian info. Minor corrections. Re-reverted information about what to call your rule file. Added info about naming network interfaces.<br /><br />
April 15th 2004 v0.53: Minor corrections. Added info about NAME{all_partitions}. Added info about other udevinfo tricks.<br /><br />
<a name="versions"></a>
<h2>Software versions used at time of writing</h2>
-Linux Kernel 2.6.7<br />
-udev 027<br />
-hotplug 20040401<br /><br />
+Linux Kernel 2.6.11<br />
+udev 056<br /><br />
<a name="terminology"></a>
<h2>Terminology: devfs, sysfs, nodes, etc.</h2>
For external mass-storage devices (e.g. usb hard disks), persistent naming is very helpful in that it allows you to hardcode accurate device paths into your <i>/etc/fstab</i>.<br /><br />
+It is important to understand that writing rules is simply a means of customizing udev behaviour. Writing rules is <b>not</b> a workaround for the problem where no device nodes for your particular device exist. If no matching rules exist, udev will create the node anyway, using the name that was supplied by the kernel.<br /><br />
+
<a name="basics"></a>
<h2>The basics of writing rules</h2>
Default udev rules are stored in <i>/etc/udev/rules.d/50-udev.rules</i>. 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, to reduce hassle while updating your udev installation in the future.<br /><br />
-Files in <i>/etc/udev/rules.d/</i> are parsed in <b>lexical</b> order. udev will stop processing rules as soon as it finds a matching rule in a file for the new item of hardware that has been detected. It is important that your own rules get processed before the udev defaults, otherwise your own naming schemes will not take effect! I suggest that you keep your own rules in a file at <i>/etc/udev/rules.d/10-local.rules</i> (this doesn't exist by default - create it). As 10 comes before 50, you know that your rules will be looked at first.<br /><br />
+Files in <i>/etc/udev/rules.d/</i> are parsed in <b>lexical</b> order. udev will stop processing rules as soon as it finds a matching rule in a file for the new item of hardware that has been detected. It is important that your own rules get processed before the udev defaults, otherwise your own naming schemes will not take effect! I suggest that you keep your own rules in a file at <i>/etc/udev/rules.d/10-local.rules</i> (this doesn't exist by default - create it). As 10 comes before 50, you know that your rules will be looked at first. It is important that the filenames of your rule files end with the <b>.rules</b> suffix, otherwise they will not be used.<br /><br />
As your own rules will effectively mask out the udev defaults which create the base /dev layout, it is recommended that you also specify devfs-style names/symlinks for the rules you write, so that you get the sensible defaults plus your own names.<br /><br />
In rule files, lines starting with a "#" are treated as comments. Every uncommented line in the file corresponds to a rule.<br /><br />
-The basic form for a rule is:
-<pre>key,[key,...] name [, symlink]</pre>
+Rules are composed of keys. Keys are seperated by commas. Some keys are used for reading and matching information, others are used for assigning information and performing actions. Matches and assignments are carried out with the expected operators (= and ==).
<ol>
-<li>At least one key must be specified. Keys are used to identify which devices the rule matches.</li>
-<li>The name parameter is required. It tells udev what that device should be named as in the /dev tree. It is written in the format NAME="<i>X</i>", where <i>X</i> is what the node will be named. You can specify multiple symlinks here, seperate them with a space.</li>
-<li>The symlink parameter (optional) allows for you to specify additional places where this node will be linked.</li>
+<li>At least one <i>identification key</i> should be provided, which will match the rule to any number of devices in the system. These are listed in the later section: <a href="#identify-keys">Identifying devices through basic keys</a>.</li>
+<li>At least one <i>assignment key</i> should be provided, to control how the resultant device node is created. These include NAME, SYMLINK, OWNER, GROUP and MODE, all of which are described in this document.</li>
</ol>
-Remember that udev will only create one node for one device. If you want it to be accessible through multiple nodes, then you have to specify the other nodes in the SYMLINK parameter.<br /><br />
+Common rules will use basic identification keys to determine the device to name, and then have a <i>NAME</i> assignement key to define the device node name. udev will only create one node for one device, so if you want it to be accessible through multiple nodes, then you have to specify the other nodes in the <i>SYMLINK</i> assignment key.<br /><br />
I'll take a slightly modified udev example rule to illustrate this:
-<blockquote><pre>BUS="usb", SYSFS{serial}="HXOLL0012202323480", NAME="lp_epson", SYMLINK="printers/epson_stylus"</pre></blockquote>
+<blockquote><pre>BUS=="usb", SYSFS{serial}=="HXOLL0012202323480", NAME="lp_epson", SYMLINK="printers/epson_stylus"</pre></blockquote>
-The keys here are the <i>BUS</i> and <i>SYSFS{serial}</i> parameters. udev will match this rule against a device that is connected through the USB bus <u>and</u> with a serial number of HXOLL0012202323480. <b>Note that <u>all</u> (as opposed to any) specified keys must be matched for udev to use the rule to name a device.</b><br />
+The identification keys here are <i>BUS</i> and <i>SYSFS{serial}</i>. The assignment keys here are <i>NAME</i> and <i>SYMLINK</i>. udev will match this rule against a device that is connected through the USB bus <u>and</u> with a serial number of HXOLL0012202323480. <b>Note that <u>all</u> (as opposed to any) specified keys must be matched for udev to use the rule to name a device.</b><br />
udev will name this node <i>lp_epson</i>, and it will be located at <i>/dev/lp_epson</i>.<br />
udev will also create a symlink to <i>/dev/lp_epson</i>, located at <i>/dev/printers/epson_stylus</i> (the printers directory will be automatically created). You can now print to your Epson printer by sending data to <i>/dev/printers/epson_stylus</i> or <i>/dev/lp_epson</i>.<br /><br />
+Any rules that you have added or modified will <b>not</b> take effect until you notify udev of this. Make sure you remember to run the following every time you modify any rule files:
+<blockquote><pre># udevstart</pre></blockquote>
+
<a name="operators"></a>
<h2>Additional automated customisation for NAME and SYMLINK parameters</h2>
There are a number of operators which can compose some or all of your NAME/SYMLINK parameters. These operators refer to kernel-data relating to the device. Take this example:
-<blockquote><pre>BUS="usb", SYSFS{vendor}="FUJIFILM", SYSFS{model}="M100", NAME="camera%n"</pre></blockquote>
+<blockquote><pre>BUS=="usb", SYSFS{vendor}=="FUJIFILM", SYSFS{model}=="M100", NAME="camera%n"</pre></blockquote>
The <i>%n</i> operator will be replaced with the "kernel number" for the camera device, to produce a NAME such as camera0, camera1, etc.<br /><br />
You can use shell style pattern matching to provide even more flexibility when writing keys. Taking a default udev rule:
-<blockquote><pre>KERNEL="ts*", NAME="input/%k"</pre></blockquote>
+<blockquote><pre>KERNEL=="ts*", NAME="input/%k"</pre></blockquote>
The * operator is used here, which matches literally anything - zero, one, or more characters of any kind. The rule literally says:<br />
You can also specify ranges that can be matched, e.g. [0-9] would match any single digit. Using an example rule from a default udev installation:
-<blockquote><pre>KERNEL="fd[0-9]*", NAME="floppy/%n"</pre></blockquote>
+<blockquote><pre>KERNEL=="fd[0-9]*", NAME="floppy/%n"</pre></blockquote>
This rule says:<br />
The valid keys are:
<ul><li>BUS - match the bus type of the device.</li>
<li>KERNEL - match the kernel device name.</li>
+<li>DRIVER - match the name of the kernel driver.</li>
+<li>SUBSYSTEM - match the kernel subsystem name.</li>
<li>ID - match the device number on the bus (e.g. PCI bus ID).</li>
<li>PLACE - match the physical position where the device is plugged into (useful for USB).</li>
The ID and PLACE keys do have their uses, but they are not commonly used in rules. This document focuses on using BUS and KERNEL keys, as well as SYSFS{...} keys (detailed in the next section). I will show how to use these keys by example.<br /><br />
-<font size="2">For extra flexibility, udev also provides keys to call external scripts and examine their result. This is out of scope of this document. Look at the udev man page for more details.</font>
+<font size="2">For extra flexibility, udev also provides keys to call external scripts and examine their result, and to examine environment variables. This is out of scope of this document. Look at the udev man page for more details.</font>
<a name="identify-sysfs"></a>
<h2>Identifying devices through SYSFS files</h2>
<font size="2">Background information: SYSFS stores many small files under a tree of directories which provide information about your hardware. One file typically contains just one "data item" - e.g. device name, manufacturer, or product ID.<br /><br />
Note that SYSFS{...} keys can be combined with the basic keys described in the previous section.</font><br /><br />
-You can use keys in the format SYSFS{<i>filename</i>} to match specific info from SYSFS, where <i>filename</i> corresponds to a file in your SYSFS tree. For example, when my camera is connected, there is a file located at <i>/sys/block/sda/device/model</i> which contains "USB 2.0M DSC". To match this, I could use the following key: SYSFS{model} = "USB 2.0M DSC"<br /><br />
+You can use keys in the format SYSFS{<i>filename</i>} to match specific info from SYSFS, where <i>filename</i> corresponds to a file in your SYSFS tree. For example, when my camera is connected, there is a file located at <i>/sys/block/sda/device/model</i> which contains "USB 2.0M DSC". To match this, I could use the following key: SYSFS{model} == "USB 2.0M DSC"<br /><br />
<b>Note that <u>any</u> file in sysfs can be matched in this manner, but if you match more than one file (through multiple keys), then you must only match files that exist in the same directory.</b> Typically, there will be several directories giving information about one device. You cannot mix and match (as shown by example below).<br /><br />
/block/sda
</pre></blockquote>
-The output of the command (shown above) is telling me that the sysfs path to start at is <i>/sys/block/sda</i>. I would now run "udevinfo -a -p /sys/block/sda". These two commands can be stringed together, like so:
+The output of the command (shown above) is telling me that the sysfs path to start at is <i>/sys/block/sda</i>. I would now run "udevinfo -a -p /sys/block/sda". These two commands can be chained together, like so:
-<blockquote><pre># udevinfo -a -p `udevinfo -q path -n /dev/sda`</pre></blockquote>
+<blockquote><pre># udevinfo -a -p $(udevinfo -q path -n /dev/sda)</pre></blockquote>
+
+<font size="2"><i>Sidenote: You may notice that we previously provided full paths (/sys/some/path) to udevinfo beforehand, but now we are providing sysfs-relative paths (/some/path) by chaining these commands. This does not matter - both types of path are accepted.</i></font><br /><br />
Moving on to rule-writing, some snipped output of the results of my "udevinfo -a -p /sys/block/sda" command is shown below, with colour added.<br />
<pre><font color="#003300">
follow the class device's "device"
looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3/3-3:1.0/host0/0:0:0:0':
- BUS="scsi"
- ID="0:0:0:0"
- SYSFS{detach_state}="0"
- SYSFS{type}="0"
- SYSFS{max_sectors}="240"
- SYSFS{device_blocked}="0"
- SYSFS{queue_depth}="1"
- SYSFS{scsi_level}="3"
- SYSFS{vendor}=" "
- SYSFS{model}="USB 2.0M DSC "
- SYSFS{rev}="1.00"
- SYSFS{online}="1"</font>
+ BUS=="scsi"
+ ID=="0:0:0:0"
+ SYSFS{detach_state}=="0"
+ SYSFS{type}=="0"
+ SYSFS{max_sectors}=="240"
+ SYSFS{device_blocked}=="0"
+ SYSFS{queue_depth}=="1"
+ SYSFS{scsi_level}=="3"
+ SYSFS{vendor}==" "
+ SYSFS{model}=="USB 2.0M DSC "
+ SYSFS{rev}=="1.00"
+ SYSFS{online}=="1"</font>
<font color="#0000FF">
looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3':
- BUS="usb"
- ID="3-3"
- SYSFS{detach_state}="0"
- SYSFS{bNumInterfaces}=" 1"
- SYSFS{bConfigurationValue}="1"
- SYSFS{bmAttributes}="c0"
- SYSFS{bMaxPower}=" 0mA"
- SYSFS{idVendor}="052b"
- SYSFS{idProduct}="1514"
- SYSFS{bcdDevice}="0100"
- SYSFS{bDeviceClass}="00"
- SYSFS{bDeviceSubClass}="00"
- SYSFS{bDeviceProtocol}="00"
- SYSFS{bNumConfigurations}="1"
- SYSFS{speed}="12"
- SYSFS{manufacturer}="Tekom Technologies, Inc"
- SYSFS{product}="USB 2.0M DSC"</font>
+ BUS=="usb"
+ ID=="3-3"
+ SYSFS{detach_state}=="0"
+ SYSFS{bNumInterfaces}==" 1"
+ SYSFS{bConfigurationValue}=="1"
+ SYSFS{bmAttributes}=="c0"
+ SYSFS{bMaxPower}==" 0mA"
+ SYSFS{idVendor}=="052b"
+ SYSFS{idProduct}=="1514"
+ SYSFS{bcdDevice}=="0100"
+ SYSFS{bDeviceClass}=="00"
+ SYSFS{bDeviceSubClass}=="00"
+ SYSFS{bDeviceProtocol}=="00"
+ SYSFS{bNumConfigurations}=="1"
+ SYSFS{speed}=="12"
+ SYSFS{manufacturer}=="Tekom Technologies, Inc"
+ SYSFS{product}=="USB 2.0M DSC"</font>
</pre>
The <i>udevinfo</i> tool provides a lot of information which you can simply copy-paste as udev rules. The reason that I have colour coded the above output is to point out that <b>you generally cannot mix and match information from different parts of the udevinfo output</b>. In the above output, I could not combine information from the different coloured sections - this is because each section of output refers to a different directory in SYSFS. For example, the following rule would not work:
-<blockquote><pre><font color="#003300">BUS="scsi"</font>, <font color="#0000FF">SYSFS{manufacturer}="Tekom Technologies, Inc"</font>, NAME="%k"</pre></blockquote>
-This rule would not work because I am combining information found in the section beginning with BUS="scsi" (green) with information only found in the blue section. The rule would work if I used BUS="usb", sticking only to information found in the blue section above.<br /><br />
+<blockquote><pre><font color="#003300">BUS=="scsi"</font>, <font color="#0000FF">SYSFS{manufacturer}=="Tekom Technologies, Inc"</font>, NAME="%k"</pre></blockquote>
+This rule would not work because I am combining information found in the section beginning with BUS=="scsi" (green) with information only found in the blue section. The rule would work if I used BUS=="usb", sticking only to information found in the blue section above.<br /><br />
You will notice that a lot of information is not relevant for writing basic rules (there is so much of it!), you should generally be looking for information that you recognise and know will not change (e.g. model name).<br /><br />
</font>
+<a name="multiple-symlinks"></a>
+<h2>Using multiple SYMLINK style rules</h2>
+Another recent feature is the ability to write rules that do not specify a <i>NAME</i>, but instead they simply specify <i>SYMLINK</i> keys. This allows you to avoid the issue where your own rules effectively mask the udev defaults.<br /><br />
+
+Take the rule:<br />
+<blockquote><pre>KERNEL=="hdc", SYMLINK="dvd"</pre></blockquote>
+
+When udev finds this rule, it will take a mental note of it. Upon finding another rule matching the same device which also includes a <i>NAME</i> parameter, udev will create the node as specified by the <i>NAME</i> parameter, plus symbolic links as specified by the <i>SYMLINK</i> parameters of both rules.<br />
+To put it into practical terms, when udev is naming nodes for my <i>hdc</i> device, it will use the default rules for block devices as usual, with the addition of my personal symlink "dvd".<br /><br />
+
+Similarly to normal rules, rules of this type will only take effect if udev is able to find them <i>before</i> it finds a rule specifying a <i>NAME</i> parameter.<br /><br />
+
+<a name="mode-owner-group"></a>
+<h2>Controlling ownership and permissions</h2>
+
+As well as controlling the naming of the device nodes which are created, udev rules also allow you to control ownership and permission attributes on that device node.<br /><br />
+
+The <i>GROUP</i> key allows you to define which unix group should own the device node. Here's an example from the udev defaults, which defines that the <i>video</i> group will own framebuffer (fb) devices:
+
+<blockquote><pre>KERNEL=="fb[0-9]*", NAME="fb/%n", SYMLINK="%k", GROUP="video"</pre></blockquote>
+
+The <i>OWNER</i> key, perhaps less useful, allows you to define which unix user should own the device node. Assuming the slightly odd situation where you would want "john" to own your floppy devices, you could use:
+
+<blockquote><pre>KERNEL=="fd[0-9]*", OWNER="john"</pre></blockquote>
+
+You'll notice in the above rule that we didn't specify any <i>NAME</i> or <i>SYMLINK</i> keys. This is similar to the <a href="#multiple-symlink">multiple symlink style</a> where udev will take a mental note that we want john to own floppy nodes, and will apply that ownership once it finds a rule which defines a <i>NAME</i> for the floppy device nodes.<br /><br />
+
+Building on the style mentioned above, you can do even more flashy things. The udev defaults use the following rule to define that all the sound device nodes shall be owned by the "audio" group:
+
+<blockquote><pre>SUBSYSTEM=="sound", GROUP="audio"</pre></blockquote>
+
+This prevents the need to excessively provide a <i>GROUP=="audio"</i> key on every following rule which names sound devices.<br /><br />
+
+udev defaults to creating nodes with unix permissions of 0660 (read/write to owner and group). There may be some situations where you do not want to use the default permissions on your device node. Fortunately, you can easily override the permissions in your rules using the <i>MODE</i> assignment key. As an example, the following rule defines that the inotify node shall be readable and writable to everyone:
+
+<blockquote><pre>KERNEL=="inotify", NAME="misc/%k", SYMLINK="%k", MODE="0666"</pre></blockquote>
+
<a name="example-printer"></a>
<h2>Example: Writing a rule for my USB printer</h2>
Running "udevinfo -a -p /sys/class/usb/lp0" provided me with a heap of info, as usual. I picked out the relevant bits for unique device identification:
<blockquote><pre>
looking at the device chain at '/sys/devices/pci0000:00/0000:00:02.1/usb3/3-3':
-BUS="usb"
-SYSFS{manufacturer}="EPSON"
-SYSFS{product}="USB Printer"
-SYSFS{serial}="L72010011070626380"
+BUS=="usb"
+SYSFS{manufacturer}=="EPSON"
+SYSFS{product}=="USB Printer"
+SYSFS{serial}=="L72010011070626380"
</pre></blockquote>
My udev rule becomes:
-<blockquote><pre>BUS="usb", SYSFS{serial}="L72010011070626380", NAME="%k", SYMLINK="epson_680"</pre></blockquote>
+<blockquote><pre>BUS=="usb", SYSFS{serial}=="L72010011070626380", NAME="%k", SYMLINK="epson_680"</pre></blockquote>
And my printer nodes exist at <i>/dev/lp0</i> (or <i>/dev/lp1</i> if another printer was plugged in beforehand) and <i>/dev/epson_680</i> <b>always</b> points at the device node for that particular printer.<br /><br />
sda1 is the node that I would like as my <i>/dev/camera</i>, as that is what gets mounted. udevinfo did not point out any useful differences between sda, sda1, and sg1. I decided that a reliable way to differentiate between these 3 nodes would be to look at the <i>KERNEL</i> name.<br /><br />
-A key such as <i>KERNEL="sd?1"</i> would match KERNEL names such as "sda1", "sdb1", "sdc1", and equally importantly, it will <b>not</b> match KERNEL names such as sda, sdb, or sg1. The purpose of this key is to ignore the <i>/dev/sda</i> and <i>/dev/sg1</i> nodes. The device is a digital camera - I would not dream of fdisking it or anything like that, so these 2 nodes are pretty useless to me. The key attempts to capture the <i>/dev/sda1</i> node, which is mountable and therefore useful!<br /><br />
+A key such as <i>KERNEL=="sd?1"</i> would match KERNEL names such as "sda1", "sdb1", "sdc1", and equally importantly, it will <b>not</b> match KERNEL names such as sda, sdb, or sg1. The purpose of this key is to ignore the <i>/dev/sda</i> and <i>/dev/sg1</i> nodes. The device is a digital camera - I would not dream of fdisking it or anything like that, so these 2 nodes are pretty useless to me. The key attempts to capture the <i>/dev/sda1</i> node, which is mountable and therefore useful!<br /><br />
As this node (sda1) is treated as a block device, looking in <i>/sys/block</i> would be a good place to start.<br /><br />
<blockquote><pre># udevinfo -a -p /sys/block/sda/sda1</pre></blockquote>
In the udevinfo output, I also noticed this bit of useful and understandable information:
-<blockquote><pre>SYSFS{product}="USB 2.0M DSC"</pre></blockquote>
+<blockquote><pre>SYSFS{product}=="USB 2.0M DSC"</pre></blockquote>
So that gives me my rule. For completeness, I also include a BUS key (this was also found in the udevinfo output).
-<blockquote><pre>BUS="usb", SYSFS{product}="USB 2.0M DSC", KERNEL="sd?1", NAME="%k", SYMLINK="camera"</pre></blockquote>
+<blockquote><pre>BUS=="usb", SYSFS{product}=="USB 2.0M DSC", KERNEL=="sd?1", NAME="%k", SYMLINK="camera"</pre></blockquote>
Now, when my camera is plugged in, it will be named <i>/dev/sda1</i> (or, if sda1 isnt available, it might be called <i>/dev/sdb1</i>) and will <b>always</b> be correctly linked to from <i>/dev/camera</i>. The /dev/sda (or sdb) node still appears as normal, but the important thing is that my custom persistent "camera" symlink points to the mountable partition.<br /><br />
<i>Carl Streeter</i>, the owner of a large USB hard disk, wrote to me and explained that unlike in my digital camera example, the <i>/dev/sda</i> node is useful to him. He pointed out that he does occasionally need to use tools such as <i>fdisk</i> and <i>hdparm</i> on that node.<br /><br />
Carl's rule is:
-<blockquote><pre>BUS="usb", KERNEL="sd*", SYSFS{product}="USB 2.0 Storage Device", NAME="%k", SYMLINK="usbhd%n"</pre></blockquote>
+<blockquote><pre>BUS=="usb", KERNEL=="sd*", SYSFS{product}=="USB 2.0 Storage Device", NAME="%k", SYMLINK="usbhd%n"</pre></blockquote>
This rule creates symlinks such as:
<ul>
udev provides a solution here - it is able to create nodes for all partitions of a block device. For every rule that you specify, the block device will have all 16 partition nodes created. To achieve this, you can simply modify the NAME key, as shown below:<br />
-<blockquote><pre>BUS="usb", SYSFS{product}="USB 2.0 Storage Device", NAME{all_partitions}="usbhd"</pre></blockquote>
+<blockquote><pre>BUS=="usb", SYSFS{product}=="USB 2.0 Storage Device", NAME{all_partitions}="usbhd"</pre></blockquote>
You will now have nodes named: usbhd, usbhd1, usbhd2, usbhd3, ..., usbhd15.<br /><br />
Still, some people (myself included) like to have nodes such as <i>/dev/dvd</i> and <i>/dev/cdrw</i> for convenience. Since we know the "hdX" values for these drives, writing rules is simple. The examples below should be self explanatory.
<blockquote><pre>
-BUS="ide", KERNEL="hdc", NAME="%k", SYMLINK="dvd cdroms/cdrom%n"
-BUS="ide", KERNEL="hdd", NAME="%k", SYMLINK="cdrw cdroms/cdrom%n"
+BUS=="ide", KERNEL=="hdc", NAME="%k", SYMLINK="dvd cdroms/cdrom%n"
+BUS=="ide", KERNEL=="hdd", NAME="%k", SYMLINK="cdrw cdroms/cdrom%n"
</pre></blockquote>
<font size="2">You may have noticed that the default 50-udev.rules file contains a rule which runs a script to produces names for block devices. Do not be confused by this - as usual, because your own rules are located in a file which is processed <b>before</b> the default rules, the defaults will not be used when naming the hardware you have written rules for.</font><br /><br />
+<a href="example-pilot"></a>
+<h2>Example: Writing a rule for your USB Visor Palm Pilot</h2>
+
+These devices work as USB-serial devices, so by default, you only get the <i>ttyUSB1</i> node. The user-space palm utilities rely on <i>/dev/pilot</i>, so you need to use a rule to create this. The following rule will do the job:<br /><br />
+
+<blockquote><pre>BUS=="usb", SYSFS{product}=="Palm Handheld", KERNEL=="ttyUSB*", SYMLINK="pilot"</pre></blockquote>
+
+This was adapted from <a href="http://www.clasohm.com/blog/one-entry?entry%5fid=12096">Carsten Clasohm's blog entry</a>, which includes a useful discussion of the situation. You may also wish to add <a href="#mode-owner-group">ownership and permission keys</a> to the rule to suit your setup.<br /><br />
+
<a name="example-iface"></a>
<h2>Example: Writing a rule to name my network interface</h2>
-An interesting new feature in recent udev versions is the ability to write rules to name your network interfaces. Network interfaces do not show up in <i>/dev</i>, but they are generally referenced by names (e.g. with <i>ifconfig</i>). Despite the differences, the rule writing process is almost identical.<br /><br />
+An interesting new feature in recent udev versions is the ability to rename your network interfaces, like the <i>nameif</i> utility does. Network interfaces do not show up in <i>/dev</i>, but they are generally referenced by names (e.g. with <i>ifconfig</i>). Despite the differences, the rule writing process is almost identical.<br /><br />
As usual, udevinfo comes to our aid in rule-writing. In my example, I wish to rename my "eth0" network device (the following output is snipped):
<blockquote><pre>
# udevinfo -a -p /sys/class/net/eth0/
looking at class device '/sys/class/net/eth0':
- SYSFS{address}="00:52:8b:d5:04:48"
+ SYSFS{address}=="00:52:8b:d5:04:48"
</pre></blockquote>
-Every network adapter has its own unique MAC-address, so I chose to use this when writing my rule. This will not change, unless you change your network card. An example rule is shown below:
+Every network adapter has its own unique MAC-address, so I chose to use this when writing my rule. This will not change, unless you change your network card. There is one caveat here: make sure you use the MAC address you obtain from udevinfo (as above), because it is case sensitive. Be careful when using utilities such as <i>ifconfig</i> as they will capitalize the letters.<br /><br />
-<blockquote><pre>KERNEL="eth*", SYSFS{address}="00:52:8b:d5:04:48", NAME="lan"</pre></blockquote>
+An example rule is shown below:
+
+<blockquote><pre>KERNEL=="eth*", SYSFS{address}=="00:52:8b:d5:04:48", NAME="lan"</pre></blockquote>
You will need to reload the net driver for this rule to take effect. You can either unload and reload the module, or simply reboot the system. You will also need to reconfigure your system to use "lan" rather than "eth0". I had some troubles getting this going (the interface wasn't being renamed) until I had completely dropped all references to eth0.<br />
After that, you should be able to use "lan" instead of "eth0" in any calls to <i>ifconfig</i> or similar utilities.<br /><br />
<li>Always use udevinfo to assist the rule-writing process. Always use udevinfo to look under /sys/block or /sys/class (it will not start reading a chain from anywhere else).</li>
<li>If you get totally stuck, use the following command to find all "dev" files under /sys (udevinfo can work on directories containing this file): find /sys -iname dev</li>
<li>If your device is a flash-card reader, usb flash-drive, or digital camera that acts as usb-storage, that is created as /dev/sdX, then start looking in /sys/block/sdX.</li>
-<li>If applicable, make sure you identify the difference between sdX and sdX1 in the above situation. This can be done with the key <i>KERNEL="sd?1"</i> to match sdX1, or <i>KERNEL="sd?"</i> to match sdX.</li>
+<li>If applicable, make sure you identify the difference between sdX and sdX1 in the above situation. This can be done with the key <i>KERNEL="sd?1"</i> to match sdX1, or <i>KERNEL=="sd?"</i> to match sdX.</li>
<li>For USB printers that are created as /dev/lpX, then you should start looking in /sys/class/usb/lpX.</li>
<li>The usb scanner driver has recently been removed from the kernel and re-implemented in userspace (as part of the SANE package). You do not (and can not) write rules for this hardware as it does not rely on specific kernel drivers.</li>
<li>Remember that unfortunately, the kernel does not export information for all devices into sysfs, meaning that you simply can't write rules for some devices yet. On 20/02/04, the udev author stated that there are 162 drivers left to convert to sysfs.</li>
</ul>
-<a name="multiple-symlinks"></a>
-<h2>Using multiple SYMLINK style rules</h2>
-Another recent feature is the ability to write rules that do not specify a <i>NAME</i>, but instead they simply specify <i>SYMLINK</i> keys. This allows you to avoid the issue where your own rules effectively mask the udev defaults.<br /><br />
+<a name="debugging"></a>
+<h2>Debugging your rules</h2>
-Take the rule:<br />
-<blockquote><pre>KERNEL="hdc", SYMLINK="dvd"</pre></blockquote>
+If you have written rules and remembered to run <b>udevstart</b> but they do not appear to be taking effect, there are a couple of ways you can debug them.<br /><br />
-When udev finds this rule, it will take a mental note of it. Upon finding another rule matching the same device which also includes a <i>NAME</i> parameter, udev will create the node as specified by the <i>NAME</i> parameter, plus symbolic links as specified by the <i>SYMLINK</i> parameters of both rules.<br />
-To put it into practical terms, when udev is naming nodes for my <i>hdc</i> device, it will use the default rules for block devices as usual, with the addition of my personal symlink "dvd".<br /><br />
-
-Similarly to normal rules, rules of this type will only take effect if udev is able to find them <i>before</i> it finds a rule specifying a <i>NAME</i> parameter.<br /><br />
-
-<a name="nvidia"></a>
-<h2>udev vs Nvidia's graphics drivers</h2>
-
-<font size="2">This section isn't really relevant to the purpose of this document, but judging from the hits I get from google, this is a hot topic. I will leave it here for now.</font><br /><br />
-
-Nvidia's graphics drivers (the closed-source ones, not the ones that come with XFree) do not work with a default installation of udev - you are unable to start X. This is because the <i>nvidia</i> module is loaded by X, but the <i>/dev/nvidia*</i> nodes are not created quick enough, so X bails out.<br /><br />
+The file <i>/etc/udev/udev.conf</i> contains a <b>udev_log</b> option. Setting this option to <i>yes</i> will cause udev to log some useful information about which rules are being applied to which nodes into the system logger. The logs will be included in /var/log/messages for most users.<br /><br />
-The solution to this problem is to autoload the <i>nvidia</i> module on bootup. Yes - you are *supposed* to do this - the <a href="ftp://download.nvidia.com/XFree86/Linux-x86/1.0-5336/README">NVidia FAQ</a> confirms this! On devfs-based systems, devfs did this automatically at bootup anyway. Your linux distribution will have created a file which you can list modules to be loaded on bootup (e.g. <i>/etc/modules.autoload.d/kernel-2.6</i> for Gentoo, <i>/etc/modules</i> for Debian).<br /><br />
+Additionally, if you know the path in <i>sysfs</i> for the node you want to create, you can use <b>udevtest</b> to see a rundown on what udev would do with the node. For example:
-This isn't all - you will also need to patch the nvidia kernel interface to export some basic info to SYSFS so that udev will create the devices. Martin Schlemmer has written a patch against the 1.0.5336 version of the nvidia drivers, which can be found <a href="http://www.gentoo.org/cgi-bin/viewcvs.cgi/*checkout*/media-video/nvidia-kernel/files/1.0.5336/NVIDIA_kernel-1.0-5336-basic-sysfs-support-v2.patch?rev=HEAD&content-type=text/plain">here</a>. The Gentoo package <i>nvidia-kernel-1.0.5336-r4</i> contains this patch.<br /><br />
+<blockquote><pre># udevtest /sys/class/sound/dsp/
+version 056
+looking at '/class/sound/dsp/'
+opened class_dev->name='dsp'
+configured rule in '/etc/udev/rules.d/50-udev.rules[132]' applied, added symlink '%k'
+configured rule in '/etc/udev/rules.d/50-udev.rules[132]' applied, 'dsp' becomes 'sound/%k'
+creating device node '/dev/sound/dsp', major = '14', minor = '3', mode = '0660', uid = '0', gid = '18'</blockquote></pre>
-Another solution is to simply create the nvidia specific nodes on bootup. X will then load the module when required, and as the nodes are already in existance, you will not run into the problem described above. Place these commands in a file that is automatically executed on bootup (e.g. <i>/etc/conf.d/local.start</i> for Gentoo):
-<blockquote><pre>
-mknod /dev/nvidia0 c 195 0
-mknod /dev/nvidiactl c 195 255
-</pre></blockquote>
-
-You should now be able to get into X with no problems.<br /><br />
+<b>udevtest</b> is only a debugging/testing tool - it does not actually create the device node, even though it says it doing so!<br /><br />
<a name="author"></a>
<h2>Author and Credits</h2>
This document is written by Daniel Drake <<a href="mailto:dan@reactivated.net">dan@reactivated.net</a>><br />
Please do not hesitate to send feedback!<br /><br />
-Additional thanks to:
-<ul>
-<li>The udev developers!</li>
-<li>agrippa_cash (usb-storage info)</li>
-<li>Carl Streeter (usb-storage info)</li>
-<li>David Watson</li>
-<li>Decibels</li>
-<li>Frank Pieczynski</li>
-<li>Feth Arezki</li>
-<li>Jim (KDE info)</li>
-<li>Johannes Jordens</li>
-<li>Kay Sievers</li>
-<li>Patrick Dreker</li>
-<li>Todd Musall</li>
-<li>Tuna</li>
-<li>Ueli Schläpfer</li>
-<li>...and anyone else who provided information or feedback</li>
-</ul>
-
-<br /><br />Copyright (C) 2003-2004 Daniel Drake<br />
+Copyright (C) 2003-2005 Daniel Drake<br />
This document is licensed under the <a href="http://www.gnu.org/licenses/gpl.html">GNU General Public License, Version 2</a>.
</body>
~ianmdlvl / elogind.git / blobdiff