Bruce Dubbs wrote:
Jürg Billeter wrote:
udev rules can/should be extended for specific devices, e.g.
KERNEL=="controlC[0-9]*", RUN+="/usr/lib/alsa.hotplug"
This brings up a question that was asked of me privately. Why are we
using udev/hotplug for alsa at all? Why not just a simple init script
that does a `alsactl restore`.
That was NOT the question that was asked privately (why would I ask this
question if I know the answer?). The (unanswewred BTW) question was
"where from (LFS or BLFS) should the reader know the reason for this
complicated setup?". Yes, LFS has the page
http://www.linuxfromscratch.org/lfs/view/6.1/chapter07/udev.html which
says "Note that on slower machines or for drivers that create a lot of
device nodes, the process of creating devices may take a few seconds to
complete. This means that some device nodes may not be immediately
accessible." However, this is insufficient, because the page doesn't
stress the essential fact that they are created _in the background_
after a modprobe command (as opposed to after udevstart). Also this
(rather abstract) context without any (suitable for LFS) examples might
be not the best place to illustrate the race.
The "no soundcards" race issue was triggered reliably with some udev
versions on my (not very slow) Celeron 1200 box if I don't install any
servers. All sane distros that use udev deal with it using the udev
handler, or BOTH the udev handler and the initscript. Let me explain the
race problem once again (sorry for reiterating old flames from lfs-dev).
in rcsysinit.d:
S55hotplug probes the snd-fm801 module, this generates a real hotplug
event and starts udev _in the background_.
S60setclock, S70console, S80localnet and S90sysctl are fast.
in rc3.d:
S10sysklogd and S20network are fast.
Then S40alsa starts, but udev is still running in the background and
thnking how to create the device nodes (maybe sleeping and waiting for
something).
When udev finishes thinking (or sleeping), it's too late. Moving the
start link to something like S99alsa will help winning the race, but
only a dev.d handler or (equivalently) a RUN=... rule avoids the race
completely.
If you want to see an artificial (non-ALSA) testcase that shows that
race very clearly, please do the following. Make sure that your kernel
has CONFIG_BLK_DEV_NBD=m. Then run the following command:
modprobe nbd ; ls /dev/nbd* | wc -l ; sleep 1 ; ls /dev/nbd* | wc -l
In the ideal situation, both "ls" commands would print 128. But in
reality, this is not the case. And with static /dev, all 128 nbd devices
are usable immediately after the "modprobe" command finishes.
Even more spectacular race example from beyond BLFS:
http://bugzilla.ubuntu.com/show_bug.cgi?id=4944
This race also creates problems for automatic Windows cloning scripts
that do something like:
# Context: NFS-root
# Install the Microsoft boot sector
dd if=/image/boot of=/dev/hda
# Create one full-sized NTFS partition for Windows
fdisk </image/fdisk-script
zcat /image/ntfs.gz >/dev/hda1
# ^^^ oops, no /dev/hda1 yet if installing to a clean machine
ntfsresize -f /dev/hda1
Adding a "sleep 1" before zcat works around the problem for me.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
