Fork: 0
tundra / deconstructing_udev
Browse code
*** empty log message ***
master
1 parent 0ad8750 commit fdb5ec5c5acc5d3fc838af4207862cebe5375ad0
@tundra tundra authored on 31 Oct 2013
Patch
Unified Split
Showing 1 changed file
View
50
■■■■■
 Deconstructing_Linux_udev_Rules.rst
because you have to be careful to insert your rule in early enough in
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
``15-ExampleRules.rules`` which should pretty much guarantee that our
when this happens. You can also force a rule reload with::
 
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
=================
We need two rules to achieve our goals above. Notice that the first
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",
OWNER:="3009", GROUP:="421", MODE:="0600",
What Does All This Mean?
========================
 
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``
 
 
 
 
 
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:
 
http://www.tundraware.com/TechnicalNotes/Deconstructing-Linux-udev-Rules