|
Home > Archive > Debian Developers > March 2004 > Bug#240125: The new broken world of 2.6, ALSA, and hotplug.
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Bug#240125: The new broken world of 2.6, ALSA, and hotplug.
|
|
| Matt Zimmerman 2004-03-31, 3:38 pm |
| 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
just that.
>
> 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
automagically.
>
> 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.
cards_exist=false
if [ -d /proc/asound/card0 ]; then
printf " ALSA appears to be compiled statically"
cards_exist=true
elif [ -z "$module_list" ]; then
printf " warning, no drivers defined in %s" "$modfile"
else
for module in $module_list; do
module_name="${module#*-}"
if modprobe "$module" > /dev/null 2>&1; then
printf " %s" "$module_name"
cards_exist=true
else
printf " %s-failed" "$module_name"
fi
done
fi
if [ "$cards_exist" = "true" ]; then
echo "."
else
echo " failed"
exit
fi
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 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.
--
- mdz
--
To UNSUBSCRIBE, email to debian-bugs-dist-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|