Re: The new broken world of 2.6, ALSA, and hotplug.
On Wed, Mar 31, 2004 at 12:08:16PM -0800, Scott Robinson wrote:
> I am not impling hotplug should load the OSS drivers. I agree with the
> latter solution of setting up a proper modutils dependency - something
> alsa-base should be doing.
I agree. This is of course not a problem with hotplug, but something that
alsa should probably have been doing anyway.
> However, I do have a problem with hotplug doing PCI enumeration.
> Certainly, I think it is something Linux has been missing. But,
> indiscriminately loading the drivers for all hardware on a computer is the
> wrong behavior, as has been demonstrated by multiple people.
I think it is the right _default_ behaviour. Seriously, how many users are
likely to want the driver for their NIC, sound card, etc. loaded, as
compared to those who are not? There are certainly exceptions, but they are
> > These mixer settings are notoriously fragile. They break with a new release
> > of ALSA. They break *horribly* when you upgrade from 2.4 to 2.6.
> I have not found them fragile.
> Furthermore, if they are so, then why is this being done?
Presumably because it's convenient for many users, and when it doesn't work,
the user just resets the settings and they're saved again on the next
shutdown, with little harm done.
On the other hand, when the mixer settings get botched on my MythTV system,
unattended recordings are interfered with, and this is a problem for me.
So, I take measures to ensure that the state file is never modified
> > As far as I know, this doesn't cause any harm. The message is misleading,
> > but the conclusion that it draws from this is OK.
> No, the conclusion it draws is wrong. The entire ALSA subsystem has _not_
> been loaded. It thus skips the rest of its initialization because of this
> incorrect assumption.
if [ -d /proc/asound/card0 ]; then
printf " ALSA appears to be compiled statically"
elif [ -z "$module_list" ]; then
printf " warning, no drivers defined in %s" "$modfile"
for module in $module_list; do
if modprobe "$module" > /dev/null 2>&1; then
printf " %s" "$module_name"
printf " %s-failed" "$module_name"
if [ "$cards_exist" = "true" ]; then
echo " failed"
That is the entirety of the code which deals with $cards_exist. It skips
loading modules (because this has already been done), and continues with
everything else. Seems correct to me.
> > udev *is* the solution to this particular problem, and personally, it
> > doesn't bother me much if all of these fragile workarounds break in order to
> > make way for the correct solution.
> udev is not the solution at this time. The package isn't not at a complete
> state (README.Debian), the upstream software is still severely alpha
> (0.023), and there are race conditions involving driver loading...
It works fine for me, and is being actively maintained and improved. What
race conditions are you referring to? I don't see any bugs in the BTS about
this. Maybe you're thinking of devfs+kmod?
> .. and let's not forget that udev currently causes another layer of
> brokeness with ALSA (#240594) and LVM. (#236346 ?)
The LVM/EVMS/device-mapper issue is a corner case, and only reveals
something which was already buggy (but happened to work anyway). See my
comments in the BTS.
> The fact is udev is not an upgrade path yet for 2.6 users. If it was, and it
> is required, where are the Depends?
I didn't say that it was required; it is the correct solution to a number of
problems. It has been a fine upgrade path for me; I have been using it
since the day I upgraded my desktop to 2.6.