[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: discover or alsa?

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.

The reverse could be (and has been, on multiple occasions) said about

The issue is that there are multiple auto-detection schemes in the
archive, currently, all of which will check what hardware is available
in the system, what driver can support that hardware, and which will
load the appropriate driver.

In this thread discover, discover1, and hotplug have been named; but
there are more -- at least at one point, we have (had) kudzu packaged
for Debian as well.

Apart from that, there's also the 'canon' way of managing modules
(/etc/modules), and a number of other packages which will load modules
to be able to do what they're installed for (hardware driver support
packages such as the ALSA ones, but also stuff such as binfmt-support
and nbd-client).

This multitude of packages doing stuff with modules is bound to break
eachother. Perhaps it's time to create a scheme which will allow
packages to load modules without stepping on eachother's toes? Such a
scheme would

* Require init scripts to ask the central module handling system
  permission to load a module, with a description of what purpose the
  module serves.
* Not do anything if the central handling system forbids it.
* Optionally keep track of what modules are loaded by what package, for
  debugging purposes.
* Allow packages to register themselves as the 'preferred' handler of
  the module at postinst time (similar to the alternatives system; this
  would solve the current issue ALSA has).
* Give the local admin the ability to override such decisions, or to
  disable the loading of certain modules.


     smog  |   bricks
 AIR  --  mud  -- FIRE
soda water |   tequila
 -- with thanks to fortune

Attachment: signature.asc
Description: Digital signature

Reply to: