Re: discover or alsa?
|--==> Wouter Verhelst writes:
WV> [1 <text/plain; us-ascii (quoted-printable)>]
WV> On Wed, Oct 13, 2004 at 10:51:46AM +0200, Marco d'Itri wrote:
>>On Oct 13, Thomas Hood <jdthood@yahoo.co.uk> wrote:
>>> Lots of users are reporting that ALSA sound doesn't "just" work when
>>> they install it. The cause of the problem is the fact that discover
>>> loads OSS modules even when ALSA modules are available. This bug cannot
>>> be worked around consistently with policy because discover offers no
>>> mechanism for blacklisting modules other than editing a conffile. The
>>> bug report against discover1 (#220616) has been tagged "wontfix" so I am
>>> not expecting the discover maintainers to solve the problem.
>>Discover should not try to load drivers for PCI devices AT ALL, we have
>>hotplug for this.
WV> The reverse could be (and has been, on multiple occasions) said about
WV> hotplug.
I thought hotplug was dealing with hot plugging devices (pcmcia, usb,
etc.)
WV> The issue is that there are multiple auto-detection schemes in the
WV> archive, currently, all of which will check what hardware is available
WV> in the system, what driver can support that hardware, and which will
WV> load the appropriate driver.
WV> In this thread discover, discover1, and hotplug have been named; but
WV> there are more -- at least at one point, we have (had) kudzu packaged
WV> for Debian as well.
WV> Apart from that, there's also the 'canon' way of managing modules
WV> (/etc/modules), and a number of other packages which will load modules
WV> to be able to do what they're installed for (hardware driver support
WV> packages such as the ALSA ones, but also stuff such as binfmt-support
WV> and nbd-client).
WV> This multitude of packages doing stuff with modules is bound to break
WV> eachother. Perhaps it's time to create a scheme which will allow
WV> packages to load modules without stepping on eachother's toes?
I definitely agree, some rational is needed here.
WV> Such a scheme would
WV> * Require init scripts to ask the central module handling system
WV> permission to load a module, with a description of what purpose the
WV> module serves.
WV> * Not do anything if the central handling system forbids it.
WV> * Optionally keep track of what modules are loaded by what package, for
WV> debugging purposes.
WV> * Allow packages to register themselves as the 'preferred' handler of
WV> the module at postinst time (similar to the alternatives system; this
WV> would solve the current issue ALSA has).
WV> * Give the local admin the ability to override such decisions, or to
WV> disable the loading of certain modules.
Seems a good scheme to me.
For the record I've made a custom discover1-data package which uses
ALSA in place of OSS:
http://apt.agnula.org/demudi/pool/local/d/discover1-data/
Cheers,
Free
Reply to: