diff --git a/Deconstructing_Linux_udev_Rules.rst b/Deconstructing_Linux_udev_Rules.rst index 808b732..72903b1 100644 --- a/Deconstructing_Linux_udev_Rules.rst +++ b/Deconstructing_Linux_udev_Rules.rst @@ -65,7 +65,7 @@ the lexical order so that it can override any subsequent defaults. Unfortunately, because of the way ``udev`` works, rules read later -in the lexical order can also *override* earlier rules if we're not careful. +in the lexical order can also *override earlier rules* if we're not careful. We'll see an example of this below, and how to fix it. In our case, we'll create our rules in the file @@ -90,10 +90,10 @@ udevadm control --reload-rules -You can also restart the ``udev`` daemon or reboot to get -the latest rules read in. It seems that the daemon restart -procedure is distro-specific so you'll have to figure out what -works on your system. +Another way to do this is to restart the ``udev`` daemon or reboot to +get the latest rules read in. Note that the daemon restart procedure +is also distro-specific, so you'll have to figure out what works on +your system. Our Example Rules @@ -103,8 +103,8 @@ rule below is broken across multiple lines to make it more readable, but it is all on one line in the actual rules file. It is possible to break rules across lines but you have to ensure that you follow the -syntax that ``udev`` expects. To keep things simple, I put the -entire rule one one line:: +syntax that ``udev`` expects. To keep things from mysteriously +breaking, I typically put the entire rule one one line:: KERNEL=="sd*", PROGRAM=="/sbin/scsi_id --whitelisted /dev/$name", RESULT=="1ATA_VBOX_HARDDISK_VB5f712327-2bb4be0c", SYMLINK+="my_fine-disk01", @@ -118,22 +118,35 @@ ======================== Rules are made up of key-value pairs separated by an operator. These -key-value pairs are separated by commas. Let's take each rule apart, -one key-value pair at a time: +key-value pairs are separated by commas. Key-value pairs either +*match* or *assign*. Match key-value pairs check to see if a +particular thing "matches" what we're looking for. Think of them as +``if`` statements in a programming language. Assignment key-value +statements take some sort of action * usually on the thing that was +previously matched*. But, you're not restricted to this. It's +entirely possible to write a rule that operates on something +completely unrelated to the matched condition. For instance, +you could write a rule that says, *reboot the computer everytime +my little brother plugs in his favorite thumbdrive*. This is, +however, considered very bad manners and may get you sent to +your room without dinner. + + +Let's take each rule apart, one key-value pair at a time: - ``KERNEL=="sd*"`` - ``PROGRAM=="/sbin/scsi_id --whitelisted /dev/$name"`` - ``RESULT=="1ATA_VBOX_HARDDISK_VB5f712327-2bb4be0c"`` - ``SYMLINK+="my_fine-disk01"`` - - ``"OWNER:="3009", GROUP:="421", MODE:="0600",`` + - ``OWNER:="3009", GROUP:="421", MODE:="0600,`` - ``RUN=="/bin/raw /dev/raw/raw1 /dev/$name"`` Now, let's look at the second rule: - ``KERNEL=="raw1"`` - ``SYMLINK+="rmy_fine-disk01"`` - - ``"OWNER:="3009", GROUP:="421", MODE:="0600"`` + - ``OWNER:="3009", GROUP:="421", MODE:="0600`` @@ -180,7 +193,7 @@ Document Revision Information ============================= -``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.107 2013/10/31 23:11:30 tundra Exp $`` +``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.108 2013/10/31 23:28:34 tundra Exp $`` You can find the latest version of this document at: