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

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,

  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:




Reply to: