From: Miklos Vajna Date: Fri, 23 Jan 2009 02:55:24 +0000 (+0100) Subject: doc: writing udev rules - refer to 'udevadm info' instead of 'udevinfo' X-Git-Tag: 174~1181 X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=elogind.git;a=commitdiff_plain;h=04f2a4fb6eded359cc8be1ba4ce33d7f7db6919f;ds=sidebyside doc: writing udev rules - refer to 'udevadm info' instead of 'udevinfo' Signed-off-by: Miklos Vajna --- diff --git a/docs/writing_udev_rules/index.html b/docs/writing_udev_rules/index.html index 5fedb3f8c..ca4fb9d31 100644 --- a/docs/writing_udev_rules/index.html +++ b/docs/writing_udev_rules/index.html @@ -52,7 +52,7 @@ The most recent version of this document can always be found at:
  • Finding suitable information from sysfs
    • @@ -429,15 +429,15 @@ In a udev rule, I could use ATTR{size}=="234441648" to identify this disk. As ud Although this serves as a useful introduction as to the structure of sysfs and exactly how udev matches values, manually trawling through sysfs is both time consuming and unnecessary.

    - -

    udevinfo

    + +

    udevadm info

    -Enter udevinfo, which is probably the most straightforward tool you can use to construct rules. All you need to know is the sysfs device path of the device in question. A trimmed example is shown below: +Enter udevadm info, which is probably the most straightforward tool you can use to construct rules. All you need to know is the sysfs device path of the device in question. A trimmed example is shown below: 

    -# udevinfo -a -p /sys/block/sda
+# udevadm info -a -p /sys/block/sda
 
   looking at device '/block/sda':
     KERNEL=="sda"
@@ -476,7 +476,7 @@ Enter udevinfo, which is probably the most straightforward tool you can

    -As you can see, udevinfo simply produces a list of attributes you can use as-is as match keys in your udev rules. From the above example, I could produce (e.g.) either of the following two rules for this device: +As you can see, udevadm info simply produces a list of attributes you can use as-is as match keys in your udev rules. From the above example, I could produce (e.g.) either of the following two rules for this device: 

    @@ -495,24 +495,24 @@ You are usually provided with a large number of attributes, and you must pick a
 
    
 
 
    
-Observe the effects of hierarchy in the udevinfo output. The green section corresponding to the device in question uses the standard match keys such as KERNEL and ATTR. The blue and maroon sections corresponding to parent devices use the parent-traversing variants such as SUBSYSTEMS and ATTRS. This is why the complexity introduced by the hierarchical structure is actually quite easy to deal with, just be sure to use the exact values that udevinfo suggests.
+Observe the effects of hierarchy in the udevadm info output. The green section corresponding to the device in question uses the standard match keys such as KERNEL and ATTR. The blue and maroon sections corresponding to parent devices use the parent-traversing variants such as SUBSYSTEMS and ATTRS. This is why the complexity introduced by the hierarchical structure is actually quite easy to deal with, just be sure to use the exact values that udevadm info suggests.
 
    
 
 
    
-Another point to note is that it is common for text attributes to appear in the udevinfo output to be padded with spaces (e.g. see ST3120827AS above). In your rules, you can either specify the extra spaces, or you can cut them off as I have done.
+Another point to note is that it is common for text attributes to appear in the udevadm info output to be padded with spaces (e.g. see ST3120827AS above). In your rules, you can either specify the extra spaces, or you can cut them off as I have done.
 
    
 
 
    
-The only complication with using udevinfo is that you are required to know the top-level device path (/sys/block/sda in the example above). This is not always obvious. However, as you are generally writing rules for device nodes which already exist, you can use udevinfo to look up the device path for you:
+The only complication with using udevadm info is that you are required to know the top-level device path (/sys/block/sda in the example above). This is not always obvious. However, as you are generally writing rules for device nodes which already exist, you can use udevadm info to look up the device path for you:
 
    
 
-
    # udevinfo -a -p $(udevinfo -q path -n /dev/sda)
    
+
    # udevadm info -a -p $(udevadm info -q path -n /dev/sda)
    
 
 
 
    Alternative methods
    
 
 
    
-Although udevinfo is almost certainly the most straightforward way of listing the exact attributes you can build rules from, some users are happier with other tools. Utilities such as usbview display a similar set of information, most of which can be used in rules.
+Although udevadm info is almost certainly the most straightforward way of listing the exact attributes you can build rules from, some users are happier with other tools. Utilities such as usbview display a similar set of information, most of which can be used in rules.
 
    
 
 
    Advanced topics
    
@@ -659,11 +659,11 @@ For example, the rule below sets the group ownership on my hard disk node, and e
 
    USB Printer
    
 
 
    
-I power on my printer, and it is assigned device node /dev/lp0. Not satisfied with such a bland name, I decide to use udevinfo to aid me in writing a rule which will provide an alternative name:
+I power on my printer, and it is assigned device node /dev/lp0. Not satisfied with such a bland name, I decide to use udevadm info to aid me in writing a rule which will provide an alternative name:
 
    
 
 
    -# udevinfo -a -p $(udevinfo -q path -n /dev/lp0)
+# udevadm info -a -p $(udevadm info -q path -n /dev/lp0)
   looking at device '/class/usb/lp0':
     KERNEL=="lp0"
     SUBSYSTEM=="usb"
@@ -695,7 +695,7 @@ Not all cameras work in this way: some of them use a non-storage protocol such a
 
    
 
 
    
-A common complication with USB camera devices is that they usually identify themselves as a disk with a single partition, in this case /dev/sdb with /dev/sdb1. The sdb node is useless to me, but sdb1 is interesting - this is the one I want to mount. There is a problem here that because sysfs is chained, the useful attributes which udevinfo produces for /dev/sdb1 are identical to the ones for /dev/sdb. This results in your rule potentially matching both the raw disk and the partition, which is not what you want, your rule should be specific.
+A common complication with USB camera devices is that they usually identify themselves as a disk with a single partition, in this case /dev/sdb with /dev/sdb1. The sdb node is useless to me, but sdb1 is interesting - this is the one I want to mount. There is a problem here that because sysfs is chained, the useful attributes which udevadm info produces for /dev/sdb1 are identical to the ones for /dev/sdb. This results in your rule potentially matching both the raw disk and the partition, which is not what you want, your rule should be specific.
 
    
 
 
    
@@ -703,7 +703,7 @@ To get around this, you simply need to think about what differs between sdb and
 
    
 
 
    -# udevinfo -a -p $(udevinfo -q path -n /dev/sdb1)
+# udevadm info -a -p $(udevadm info -q path -n /dev/sdb1)
   looking at device '/block/sdb/sdb1':
     KERNEL=="sdb1"
     SUBSYSTEM=="block"
@@ -781,7 +781,7 @@ These devices work as USB-serial devices, so by default, you only get the tt
 
    SUBSYSTEMS=="usb", ATTRS{product}=="Palm Handheld", KERNEL=="ttyUSB*", SYMLINK+="pilot"
    
 
 
    
-Note that the product string seems to vary from product to product, so make sure that you check (using udevinfo) which one applies to you.
+Note that the product string seems to vary from product to product, so make sure that you check (using udevadm info) which one applies to you.
 
    
 
 
@@ -808,11 +808,11 @@ Even though they are referenced by names, network interfaces typically do not ha
 
    
 
 
    
-It makes sense to simply match the MAC address of your interface in the rule, as this is unique. However, make sure that you use the exact MAC address as shown as udevinfo, because if you do not match the case exactly, your rule will not work.
+It makes sense to simply match the MAC address of your interface in the rule, as this is unique. However, make sure that you use the exact MAC address as shown as udevadm info, because if you do not match the case exactly, your rule will not work.
 
    
 
 
    -# udevinfo -a -p /sys/class/net/eth0
+# udevadm info -a -p /sys/class/net/eth0
   looking at class device '/sys/class/net/eth0':
     KERNEL=="eth0"
     ATTR{address}=="00:52:8b:d5:04:48"