UDEV - Not Leaving Well Enough Alone

alupu at verizon.net alupu at verizon.net
Fri Nov 20 20:10:52 PST 2009


Hello,

System:  Development LFS
 i686-pc-linux-gnu, 2.6.31.6, Udev-147

In files
  /lib/udev/rules.d/50-udev-default.rules
  /etc/udev/rules.d/55-lfs.rules
there's a rule 
    KERNEL=="fd[0-9]", ACTION=="add|change", \
     ATTRS{cmos}=="?*", RUN+="create_floppy_devices"
    etc.
which creates (in /dev) a number of krazy devices named,

fd0u1120  fd0u1600  fd0u1722  fd0u1760  fd0u1920
fd0u720  fd0u820 fd0u1040  fd0u1440  fd0u1680
fd0u1743  fd0u1840  fd0u360   fd0u800  fd0u830

In the past, I was able to avoid this creation
of unnecessary fd nodes.  (Ironically, cluttering up
the /dev directory runs contrary to the fundamental
spirit of UDEV.) by using a simple, permanent
"disabling" rule in a file "49-... .rules" in our
'/etc/udev/rules.d' directory containing a line like,

KERNEL=="fd[0-9]", ATTRS{cmos}=="?*", OPTION="last_rule"
(NOTE: in the UDEV world, 49 beats 50 and 50 beats 55)

and I had peace all this time.

Unfortunately, sometime between 146 and 147, 
a UDEV developer decided to quietly (i.e., without
explanation) pull the "last_rule" OPTION right from
under me, so now (147+) I am forced to track files
like 50 and 55 and painstakingly comment out any 
offending rule by hand to prevent the /dev mess up.

Questions:
1. How can I disable a rule now without using the
simple "last_rule" trick like in the olden times?
I did scan the "new" OPTIONS in the latest udev
manual but none seemed too attractive, at least
to my untrained eyes.

2. Does anybody keep track of duplicates?
True, the 50 adds the "change" to the 55 rule, but the
"change" (whatever that means in practical terms),
is really necessary?

3. Who needs these "CMOS" (NEC?) floppies at
end of 2009?  Because of the recession, maybe?

Thanks to anybody who would bring some clarifications.

-- Alex



More information about the lfs-support mailing list