Edits and cleanup.

Fork: 0

tundra / deconstructing_udev

Browse code Edits and cleanup. master
1 parent 8933bae commit 944915301cc768cea183743086c8512a6d51269b tundra authored on 31 Oct 2013

Patch

Unified Split

Showing 1 changed file

                Ignore Space
               Show notes
              View
            
          
          36 ■■■■■
          Deconstructing_Linux_udev_Rules.rst
 ``15-ExampleRules.rules`` which should pretty much guarantee that our
rules will be the first ones read.
 
 
How Does ``udev`` Read Rules
============================
How Does ``udev`` Read Rules?
=============================
 
When ``udev`` first starts, or any time it is informed that rules have
been changed, it first reads a set of system-wide default rules in
``/lib/udev/rules.d/``.  Then it reads the rules in
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
every time 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.  You may, however, have a career developing
websites for the US government healthcare initiatives.
instance, you could write a rule that says, *reboot the computer every
time 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.  You may, however, have a career developing websites
for US government healthcare initiatives.
 
Let's take each rule apart, one key-value pair at a time:
 
 
an Officially Bad Idea (tm) because there is no guarantee that the
same device will get the same major/minor device numbers every time.
These numbers are generated by the kernel and are based on the order
of driver/device loading, the next free number available to the
kernel, and the cosmic ray count in Goscratchistan.  Only the
kernel, and the cosmic ray count in Lower Goscratchistan.  Only the
``wwid`` (or an equivalent ``UUID``) is guaranteed to be unique, so
that's what we used here.
 
If we got this far, it means that all our matching tests were
    for software to use when referencing this disk.  Say I'm writing
    an application.  We don't have to know where the disk is mounted.
    We just have to always refer to ``/dev/my_fine_disk01`` and let
    all this ``udev`` magic do the hard stuff.  Remember, it's our job
    as Snotty Systems Engineers (sm) to relieve Applications Programmers of
    as Snotty Systems Engineers (tm) to relieve Applications Programmers of
    as much thinking as possible.  Really, it is.  Look it up in the
    job description.
   
 
 
    "But why", you may ask, "are you using the ``RUN==`` construct?
    Isn't that what ``PROGRAM==`` does?"  Not exactly, Grasshopper.
    ``PROGRAM==`` *always* runs regardless of prior matching.
    ``RUN==`` *only* runs if all prior matching has been successful.
    That's because ``PROGRAM==`` is itself a *matching* key-value
    construct.  It's used to *figure out* whether a match has
    taken place.  It this has to run every time.   ``RUN==``,
    on the other hand,  *only* runs if all prior matching has
    been successful.
 
    Why is that important here?  Say we boot the system, and the
    kernel discovers drives ``/dev/sdh, /dev/sdi,`` and ``/dev/sdj``
    and let's suppose that the first one has the matching ``wwid``.
 
    The DBAs can then configure their database engines to look for the
    symlink name and never worry about what the underlying node
    mapping is for the raw device.  Just as with Applications
    Programmers, we Snotty Systems Engineers (sm) are required - by law -
    to make things as easy as possible for DBAs.  Again, you are
    referred to the job description.
    Programmers, we Snotty Systems Engineers (tm) are required - by
    law - to make things as easy as possible for DBAs.  This one isn't
    actually in the job description, it's just an act of kindness.
 
 
  - ``OWNER:="3009", GROUP:="421", MODE:="0600``
 
 
Document Revision Information
=============================
 
``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.114 2013/11/01 03:00:13 tundra Exp $``
``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.115 2013/11/01 03:21:43 tundra Exp $``
 
You can find the latest version of this document at:
 
  http://www.tundraware.com/TechnicalNotes/Deconstructing-Linux-udev-Rules
 ``15-ExampleRules.rules`` which should pretty much guarantee that our
 rules will be the first ones read.
+How Does ``udev`` Read Rules
+============================
+How Does ``udev`` Read Rules?
+=============================
 When ``udev`` first starts, or any time it is informed that rules have
 been changed, it first reads a set of system-wide default rules in
 ``/lib/udev/rules.d/``.  Then it reads the rules in
 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
+every time 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.  You may, however, have a career developing
+websites for the US government healthcare initiatives.
+instance, you could write a rule that says, *reboot the computer every
+time 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.  You may, however, have a career developing websites
+for US government healthcare initiatives.
 Let's take each rule apart, one key-value pair at a time:
 an Officially Bad Idea (tm) because there is no guarantee that the
 same device will get the same major/minor device numbers every time.
 These numbers are generated by the kernel and are based on the order
 of driver/device loading, the next free number available to the
+kernel, and the cosmic ray count in Goscratchistan.  Only the
+kernel, and the cosmic ray count in Lower Goscratchistan.  Only the
 ``wwid`` (or an equivalent ``UUID``) is guaranteed to be unique, so
 that's what we used here.
 If we got this far, it means that all our matching tests were
     for software to use when referencing this disk.  Say I'm writing
     an application.  We don't have to know where the disk is mounted.
     We just have to always refer to ``/dev/my_fine_disk01`` and let
     all this ``udev`` magic do the hard stuff.  Remember, it's our job
+    as Snotty Systems Engineers (sm) to relieve Applications Programmers of
+    as Snotty Systems Engineers (tm) to relieve Applications Programmers of
     as much thinking as possible.  Really, it is.  Look it up in the
     job description.
     "But why", you may ask, "are you using the ``RUN==`` construct?
     Isn't that what ``PROGRAM==`` does?"  Not exactly, Grasshopper.
     ``PROGRAM==`` *always* runs regardless of prior matching.
+    ``RUN==`` *only* runs if all prior matching has been successful.
+    That's because ``PROGRAM==`` is itself a *matching* key-value
+    construct.  It's used to *figure out* whether a match has
+    taken place.  It this has to run every time.   ``RUN==``,
+    on the other hand,  *only* runs if all prior matching has
+    been successful.
     Why is that important here?  Say we boot the system, and the
     kernel discovers drives ``/dev/sdh, /dev/sdi,`` and ``/dev/sdj``
     and let's suppose that the first one has the matching ``wwid``.
     The DBAs can then configure their database engines to look for the
     symlink name and never worry about what the underlying node
     mapping is for the raw device.  Just as with Applications
+    Programmers, we Snotty Systems Engineers (sm) are required - by law -
+    to make things as easy as possible for DBAs.  Again, you are
+    referred to the job description.
+    Programmers, we Snotty Systems Engineers (tm) are required - by
+    law - to make things as easy as possible for DBAs.  This one isn't
+    actually in the job description, it's just an act of kindness.
   - ``OWNER:="3009", GROUP:="421", MODE:="0600``
 Document Revision Information
 =============================
+``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.114 2013/11/01 03:00:13 tundra Exp $``
+``$Id: Deconstructing_Linux_udev_Rules.rst,v 1.115 2013/11/01 03:21:43 tundra Exp $``
 You can find the latest version of this document at:
   http://www.tundraware.com/TechnicalNotes/Deconstructing-Linux-udev-Rules

Show line notes below