From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Drake Date: Thu, 15 Apr 2004 21:58:30 +0000 Subject: [Patch] Update writing udev rules docs Message-Id: <407F0586.50809@reactivated.net> MIME-Version: 1 Content-Type: multipart/mixed; boundary="------------070805010202020906040905" List-Id: To: linux-hotplug@vger.kernel.org This is a multi-part message in MIME format. --------------070805010202020906040905 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi Greg, Here's an update for the writing udev rules document. - Minor corrections/clarifications - Added info about using NAME{all_partitions} - Added more info about udevinfo, simplifying the rule-writing process You can ignore the diff I sent you yesterday - according to the 20040415 bk snapshot on codemonkey.org, you haven't applied it yet. This patch incorporates that update, and some other changes I just made. Thanks Daniel --------------070805010202020906040905 Content-Type: text/plain; name="writing_udev_rules-0.53-update.patch" Content-Disposition: inline; filename="writing_udev_rules-0.53-update.patch" Content-Transfer-Encoding: quoted-printable diff -urN udev-bk20040415/docs/writing_udev_rules/index.html udev-dsd/doc= s/writing_udev_rules/index.html --- udev-bk20040415/docs/writing_udev_rules/index.html 2004-04-15 01:00:3= 3.000000000 +0100 +++ udev-dsd/docs/writing_udev_rules/index.html 2004-04-15 22:33:07.00000= 0000 +0100 @@ -1,6 +1,6 @@ -Writing udev rules [reactivated.net] +Writing udev rules =20 @@ -8,7 +8,7 @@ =20

Writing udev rules

by Daniel Drake (dsd)
-Version 0.51

+Version 0.53

=20 The most recent version of this document can always be found at:
http://www.reactiva= ted.net/udevrules.php @@ -23,7 +23,7 @@
  • Why? (The purpose of this document)
  • The basics of writing rules
  • Additional automated customisation for NAME a= nd SYMLINK parameters
    • -
  • Using regular expressions and wildcards in keys<= /a>
    • +
  • Using shell-style pattern matching in keys
  • Key-writing basics
  • Identifying devices through basic keys
  • Identifying devices through SYSFS files<= /a>
    • @@ -51,8 +51,9 @@ =20

    History

    =20 +April 15th 2004: Minor corrections. Added info about NAME{all_partitions= }. Added info about other udevinfo tricks.

    +April 14th 2004: Reverted to suggesting using "udev.rules" until the ude= v defaults allow for other files. Minor work.

    April 6th 2004: I now write suggest users to use their own "local.rules"= file rather than prepending "udev.rules".

    - April 3rd 2004: Minor cleanups and preparations for possible inclusion i= n the udev distribution.

    February 15th 2004: Initial publication.

    February 18th 2004: Fixed a small omission in an example. Updated sectio= n on identifying mass-storage devices. Updated section on nvidia.
    <= br /> @@ -96,11 +97,13 @@

    The basics of writing rules

    =20 -When populating /dev, udev decides which nodes to include, and ho= w to name them, by reading a rules file. The default rules file includes = some examples, and defaults to giving a devfs-style layout. The examples = may safely be removed, but it is generally sensible to keep the devfs rul= es and simply make your own amendments and modifications.

    +When populating /dev, udev decides which nodes to include, and ho= w to name them, by reading a rules file. This rules file is processed fro= m top to bottom, and udev will stop processing rules for a device once it= finds one that matches.

    + +Default udev rules are stored in /etc/udev/udev.rules. The defaul= t file includes some examples, and defaults to giving a devfs-style layou= t. The examples may safely be removed, but it is generally sensible to ke= ep the devfs rules and simply make your own amendments and modifications.= You should write your rules in this file, above the examples and = default devfs-style rules.

    =20 -Default udev rules are stored in /etc/udev/udev.rules. You may fi= nd it interesting to look over this file - it includes a few examples, an= d then some default rules proving a devfs-style /dev layout. However, you= should not write rules into this file directly, to reduce hassle while u= pdating your udev installation in the future.

    + =20 As your own rules will effectively mask out the udev defaults which crea= te the base /dev layout, it is recommended that you also specify devfs-st= yle names/symlinks for the rules you write, so that you get the sensible = defaults plus your own names.

    =20 @@ -141,9 +144,9 @@ A full list of operators, with explanations, can be fou= nd in the udev man page.

    =20 -

    Using regular expressions and wildcards in keys

    +

    Using shell-style pattern matching in keys

    =20 -You can use wildcards and basic regular-expression style matching to pro= vide even more flexibility when writing keys. Taking a default udev rule: +You can use shell style pattern matching to provide even more flexibilit= y when writing keys. Taking a default udev rule: =20 
    KERNEL=3D"ts*", NAME=3D"input/%k"
    =20 @@ -164,7 +167,7 @@ =20
    Match a device identified by a KERNEL name starting with the= letters "fd", followed by any single digit, optionally followed by anyth= ing at all. Name the device with the kernel number of the device (%n) und= er the floppy directory.
    =20 -You can use these wildcards/regular-expression matches in any type of ke= y, including both basic keys and sysfs-based identification (see below fo= r explanations of these key types).

    +You can use these wildcards/pattern matches in any type of key, includin= g both basic keys and sysfs-based identification (see below for explanati= ons of these key types).

    =20 I have purposely left out some information on this topi= c (particularly the flexibility of using [ ] operators) that is out of th= e scope of basic rule-writing documentation. More information on this top= ic can be found in the udev man page.

    =20 @@ -209,7 +212,18 @@ Once you have found a directory of this type, you can use the following = command to assist you in the creation of writing keys for udev rules: 
    # udevinfo -a -p /sys/path/to/hardware/info
    =20 -Some snipped output of the results of my "udevinfo -a -p /sys/block/sda"= command is shown below, with colour added.
    +You may find that finding the correct place in /sys to run udevin= fo on is not obvious. Chances are the device you just plugged in has alre= ady careted a device node (e.g. /dev/sda), in which case, udevinfo= can be helpful! Taking the example of my /dev/sda node, running t= he following command will point you to the appropriate area of sysfs: +
    +# udevinfo -q path -n /dev/sda
+
+/block/sda
+
    + +The output of the command (shown above) is telling me that the sysfs pat= h to start at is /sys/block/sda. I would now run "udevinfo -a -p /= sys/block/sda". These two commands can be stringed together, like so: + +
    # udevinfo -a -p `udevinfo -q path -n /dev/sda`
    + +Moving on to rule-writing, some snipped output of the results of my "ude= vinfo -a -p /sys/block/sda" command is shown below, with colour added. =20 
    
 follow the class device's "device"
@@ -262,14 +276,10 @@
 
 
    Example: Writing a rule for my USB printer
    
=20
-After plugging in my printer, I started looking around some /sys directo=
ries for a relevant place to start. I didn't get anywhere, but I noticed =
that my printer had been given device node /dev/lp0. I used this c=
ommand sequence to find an answer:
+After plugging in my printer, I started looking around some /sys directo=
ries for a relevant place to start. I didn't get anywhere, but I noticed =
that my printer had been given device node /dev/lp0. udevinfo was =
able to provide me with a useful path:
 
    -# cd /sys
-# find | grep lp0
-./class/usb/lp0
-./class/usb/lp0/dev
-./class/usb/lp0/driver
-./class/usb/lp0/device
+# udevinfo -q path -n /dev/lp0
+/class/usb/lp0
 
    
=20
 Running "udevinfo -a -p /sys/class/usb/lp0" provided me with a heap of i=
nfo, as usual. I picked out the relevant bits for unique device identific=
ation:
@@ -326,14 +336,23 @@
=20
 This rule creates symlinks such as:
 
      
-
    • /dev/usbhdd - The fdiskable node
      • 
-
    • /dev/usbhdd1 - The first partition (mountable)
      • 
-
    • /dev/usbhdd2 - The second partition (mountable)
      • 
+
    • /dev/usbhd - The fdiskable node
      • 
+
    • /dev/usbhd1 - The first partition (mountable)
      • 
+
    • /dev/usbhd2 - The second partition (mountable)
      • 
=20
 
    
=20
 We agreed that depending on the situation and device in question, there =
are reasons for both wanting and not wanting the non-mountable /dev/sd=
a node. Use whichever setup suits you best.

    
=20
+Another difficult situation is having a multiple-slot USB-storage card r=
eader. These types of device generally do not inform the host when new ca=
rds are plugged in or out, so plugging a card into an unused slot while t=
he reader is plugged in will not create the extra device node needed for =
mounting!
    
+This problem also applies to other USB disks - e.g. if you create a new =
partition, the new partition node will not appear until you re-plug the d=
evice.

    
+
+udev provides a solution here - it is able to create nodes for all parti=
tions of a block device. For every rule that you specify, the block devic=
e will have all 16 partition nodes created. To achieve this, you can simp=
ly modify the NAME key, as shown below:
    
+
+
    BUS=3D"usb", SYSFS{product}=3D"USB 2.0 Storage Device",=
 NAME{all_partitions}=3D"usbhd%n"
    
+
+You will now have nodes named: usbhd, usbhd1, usbhd2, usbhd3, ..., usbhd=
15.

    
+
 
 
    Example: Writing convenience rules for my CD drives
    
 I have two CD drives in my PC - a DVD reader, and a CD rewriter. My DVD =
is hdc and my CDRW is hdd. I would not expect this to change, unless I ma=
nually changed the cabling of my system.

    
@@ -346,13 +365,14 @@
 BUS=3D"ide", KERNEL=3D"hdd", NAME=3D"%k", SYMLINK=3D"cdrw cdroms/cdrom%n=
"
    =20 -You may have noticed that the default udev.rules file c= ontains a rule which runs a script to produces names for block devices. D= o not be confused by this - as usual, because your own rules in local.= rules are processed before the default rules, the default rule= s will not be used when naming the hardware you have written rules for.

    +You may have noticed that the default udev.rules file c= ontains a rule which runs a script to produces names for block devices. D= o not be confused by this - as usual, because your own rules are located = at the top of the rules file, they are processed before the defaul= t rules, so the default rules will not be used when naming the hardware y= ou have written rules for.

    =20

    Tips for finding the appropriate places in SYSFS

    I'm looking for some more device specific tips here. Plea= se contact me with any you can provide. =20
      +
    • If the device you are looking to write rules for has created a devic= e node under /dev, then you are in luck! Run the following command to get= an appropriate /sys path: udevinfo -q path -n /dev/yournode
    • Always use udevinfo to assist the rule-writing process. Always use u= devinfo to look under /sys/block or /sys/class (it will not start reading= a chain from anywhere else).
    • 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
    • If your device is a flash-card reader, usb flash-drive, or digital c= amera that acts as usb-storage, that is created as /dev/sdX, then start l= ooking in /sys/block/sdX.
      • @@ -394,8 +414,11 @@
    • Carl Streeter (usb-storage info)
    • Decibels
    • Frank Pieczynski
      • +
    • Feth Arezki
    • Jim (KDE info)
      • +
    • Kay Sievers
    • Patrick Dreker
      • +
    • Todd Musall
    • Tuna
    • Ueli Schl=E4pfer
    • ...and anyone else who provided information or feedback
      • @@ -405,4 +428,4 @@ This document is licensed under the GNU General Public License, Version 2. =20 - \ No newline at end of file + --------------070805010202020906040905-- ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel