DJ Lucas wrote:
Alexander E. Patrakov wrote:
Bruce Dubbs wrote:
Do we have a proposed fix? There are a couple of suggestions in the
bug, but I don't see anything definitive.
I propose writing a dev.d handler instead of the start section of thecurrent
alsa bootscript, and adding text that it doesn't work when the driver is a
non-module and /usr is on the separate partition.
I really don't like this...only modules are supported?
non-module, /usr is not a separate partition => works
module, /usr is not a separate partition => works
non-module, /usr is a separate partition => broken (upstream problem)
module, /usr is a separate partition => works
This brokenness has been reported to linux-hotplug-devel, they suggest
moving alsactl to /sbin and its libraries to /lib. Of course they cannot
be serious.
Unfortunately, I cannot find my own post there. Should I repost?
As is now, /usr
on a separate partition is good, and both modules and built-in are
supported...the 'sit n spin' method sucks too, but it'll cover the most
hardware. We can limit the wait time for udev to something sane like 10
seconds (that may even be pushing it a bit) using something _like_ this:
count=0
nodevice=0
while [ ! -f /dev/dsp ]; do
Bad, some people prefer pure-ALSA systems, therefore no /dev/dsp.
Also one has to take into account that delays between finished modprobe
and usable device node occur even without udev. E.g., this alias is
broken/wontfix even without udev/hotplug:
alias snd-card-0 snd-usb-audio
Since USB audio is a rather important case, I think that delaying the
boot brocess just because the user didn't turn the speakers on is a bad
idea. Also, "alsactl restore" in dev.d handler works without extra
delays in both "speakers on" and "speakers off" cases, and even doesn't
lose volume settings when one turns speakers off and then on.
BTW Debian has both the dev.d handler, the post-modprobe handler (with
sleep), and the regular initscript for those who have no udev and live
with a custom non-modular kernel. In all cases, they hide the "no
devices" error. I don't think BLFS should turn into such a monster.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
