Re: discover or alsa?
On Wed, 13 Oct 2004 15:30:36 -0500, Ian Murdock wrote: I will add this support to discover2 as well, since it currently suffers from the same problem as discover1 with respect to blacklisting modules
discover and hotplug must be able to co-exists (was Re: discover or alsa?)
hi for as much as I loved the religion war of people-liking-discover against p-l-hotplug, (and then of p-l-udev vs p-l-devf vs p-l-/dev ), I think nobody stated the most important point: discover and hotplug must be able to co-exists. The reason is in the dependencies: indeed xserver-xfree86 Suggests: discover (and indeed they were mantained by B.Robinson) whereas gnome-volume-manager Depends: udev , udev Depends: hotplug so, on a typical install of Debian, it is quite possible that discover and hotplug are installed at the same time. AFAIK, discover is needed by xserver-xfree86 only to detect and configure the server - but this is a very important functionality for the average user, and I would not neglect its usefulness. Unless someone may go and rewrite xserver-xfree86 to suggest 'hotplug | discover', and use any of the two. (hotplug has a much wider list of rdependencies than discover, so it may be installed nonetheless). (Ops I am becoming religious myself!) a.
Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)
I agree that hotplug and discover must be able to co-exist on a system. And I believe they mostly do, as I have both installed. :) [A Mennucc] Unless someone may go and rewrite xserver-xfree86 to suggest 'hotplug | discover', and use any of the two. (hotplug has a much wider list of rdependencies than discover, so it may be installed nonetheless). (Ops I am becoming religious myself!) How do I use hotplug to get the correct XFree86 driver for a given video card? I thought hotplug only did kernel modules.
Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)
On Thu, Oct 21, 2004 at 09:52:10AM +0200, A Mennucc wrote: so, on a typical install of Debian, it is quite possible that discover and hotplug are installed at the same time. It's more than quite possible, it's what you get after installing sarge, except if it changed since the snapshot I tried. Mike
Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)
Petter Reinholdtsen wrote: I agree that hotplug and discover must be able to co-exist on a system. And I believe they mostly do, as I have both installed. :) [A Mennucc] Unless someone may go and rewrite xserver-xfree86 to suggest 'hotplug | discover', and use any of the two. (hotplug has a much wider list of rdependencies than discover, so it may be installed nonetheless). (Ops I am becoming religious myself!) How do I use hotplug to get the correct XFree86 driver for a given video card? I thought hotplug only did kernel modules. ops. Since hotplug deals with PCI cards, I assumed that it would know of video cards as well; if this is not the case, then maybe the best way out would be that: mantainers of discover split discover in two, discover-X11 and discover (all the rest), whereas discover-X11 will be used by xserver-xfree86, but it will not touch anything else; and everybody will be happy ever after. a.
Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)
On Oct 21, A Mennucc [EMAIL PROTECTED] wrote: Unless someone may go and rewrite xserver-xfree86 to suggest 'hotplug | discover', and use any of the two. (hotplug has a much wider list of Hotplug does not know about X drivers and is not supposed to. I think that the correct solution is to ship discover with autoloading of USB and PCI devices turned off by default. -- ciao, | Marco | [8659 etDocPnL97LuY] signature.asc Description: Digital signature
Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)
[Marco d'Itri] Hotplug does not know about X drivers and is not supposed to. Right. That is what I suspected. So it can not replace discover, kudzy, or any of the other packages capable of providing X driver info. I think that the correct solution is to ship discover with autoloading of USB and PCI devices turned off by default. At least it sounds like a good idea to have such option. The work is done in the init.d-script. I'm sure patches to make it optional to load kernel modules at boot time are welcome. :) I'm not sure if it should be off by default. But that is a different discussion. :)
Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)
On Oct 21, Petter Reinholdtsen [EMAIL PROTECTED] wrote: I'm not sure if it should be off by default. But that is a different discussion. :) discover cannot load hotplugged devices, so to me it looks like a good idea to use the same program to do both. Reliably reproducible bugs are better than inconsistent behaviour. :-) -- ciao, | Marco | [8669 esXr1it..byJE] signature.asc Description: Digital signature
Re: discover and hotplug must be able to co-exists (was Re: discover or alsa?)
[Marco d'Itri] discover cannot load hotplugged devices, so to me it looks like a good idea to use the same program to do both. Reliably reproducible bugs are better than inconsistent behaviour. :-) I'm not really interested in participating in that discussion. Anyway, if you make a patch, please make the default configurable using debconf preseeding, with a hidden debconf question (only use db_get). This way it is easy to change the default for us making custom debian distributions. :)
Re: discover or alsa?
On Thu, Oct 14, 2004 at 03:17:59PM -0400, sean finney wrote: On Thu, Oct 14, 2004 at 12:37:07PM -0600, Jeremy Nickurak wrote: For what it's worth, hotplug recently had a similar issue on a test install for me: it actually loaded both OSS and ALSA drivers for my soundcard. likewise for me. i've found that after a fresh debian install, one of the first things i have to do is add a bunch of modules to hotplug's blacklist. Ditto, which is what pisses me off about hotplug. It seems far more indiscriminate in its module loading than discover does. regards Andrew -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten!
Re: discover or alsa?
On Thu, Oct 14, 2004 at 03:17:59PM -0400, sean finney wrote: likewise for me. i've found that after a fresh debian install, one of the first things i have to do is add a bunch of modules to hotplug's blacklist. the first thing I had to do after a fresh install was to remove discover1 to avoid its load of the OSS module, while hotplug was already trying to load everything that discover1 did load. Mike
Re: discover or alsa?
Jeremy Nickurak wrote: For what it's worth, hotplug recently had a similar issue on a test install for me: it actually loaded both OSS and ALSA drivers for my soundcard. First make sure that you don't have either discover1 or discover installed. Are the modules loaded by hotplug listed in your /etc/hotplug/blacklist.d/alsa-base file? If so then please file a bug report against hotplug. If not then please file a bug report against alsa-base. In either case, please provide the name of the module and all other information that seems relevant. sean finney wrote: likewise for me. i've found that after a fresh debian install, one of the first things i have to do is add a bunch of modules to hotplug's blacklist. If these are OSS modules, please file a bug report against alsa-base letting us know which additional module names need to be added to our blacklist files /etc/hotplug/blacklist.d/alsa-base and /etc/discover.d/alsa-base. -- Thomas Hood
Re: discover or alsa?
Ian Murdock wrote: I will add this support to discover2 as well, since it currently suffers from the same problem as discover1 with respect to blacklisting modules. Thanks. We will release a new version of alsa-base very shortly that makes use of this feature. -- Thomas Hood
Re: discover or alsa?
On mer, 2004-10-13 at 10:30 +0200, Thomas Hood 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. Given these facts, what should the ALSA packaging team do? It seems that the alsa packages should Conflict with discover and discover1. -- Thomas Hood For what it's worth, hotplug recently had a similar issue on a test install for me: it actually loaded both OSS and ALSA drivers for my soundcard. signature.asc Description: This is a digitally signed message part
Re: discover or alsa?
On Thu, Oct 14, 2004 at 12:37:07PM -0600, Jeremy Nickurak wrote: For what it's worth, hotplug recently had a similar issue on a test install for me: it actually loaded both OSS and ALSA drivers for my soundcard. likewise for me. i've found that after a fresh debian install, one of the first things i have to do is add a bunch of modules to hotplug's blacklist. sean -- signature.asc Description: Digital signature
discover or alsa?
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. Given these facts, what should the ALSA packaging team do? It seems that the alsa packages should Conflict with discover and discover1. -- Thomas Hood
Re: discover or alsa?
[Thomas Hood] Given these facts, what should the ALSA packaging team do? It seems that the alsa packages should Conflict with discover and discover1. Isn't this only a problem with discover1? I thought discover (v2) had a mechanism to detect if OSS or ALSA was used. It is probably better to discuss this with the discover1 and discover (v2) maintainers and authors over at debian-boot and discover-workers.
Re: discover or alsa?
On Wed, 2004-10-13 at 10:57, Petter Reinholdtsen wrote: [Thomas Hood] Isn't this only a problem with discover1? I thought discover (v2) had a mechanism to detect if OSS or ALSA was used. If there is such a mechanism then it isn't working. It is probably better to discuss this with the discover1 and discover (v2) maintainers and authors over at debian-boot and discover-workers. The discover maintainers ended that discussion with a decision not to fix the bug in discover1. The bug _may_ be fixed in discover at some time in the future, presumably post-sarge. The remaining question is how alsa should deal with this situation. Conflict with discover[1]? Add a paragraph to the alsa-base README telling how to fix the problem by hand? Add code to the alsa initscript which rmmods OSS modules? -- Thomas Hood
Re: discover or alsa?
On Oct 13, Thomas Hood [EMAIL PROTECTED] 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. -- ciao, | Marco | [8529 riJkWPDrTv6mA] signature.asc Description: Digital signature
Re: discover or alsa?
On Wed, Oct 13, 2004 at 10:51:46AM +0200, Marco d'Itri wrote: On Oct 13, Thomas Hood [EMAIL PROTECTED] 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 hotplug. 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. Comments? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
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 [EMAIL PROTECTED] 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
Re: discover or alsa?
On Wed, Oct 13, 2004 at 02:14:24PM +0200, Free Ekanayaka said |--== 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 [EMAIL PROTECTED] 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.) PCI (on special motherboards) is hotpluggable :-) -rob -- Words of the day: CBNRC Glock SCUD missile Janet Reno clandestine NASA ASIO
Re: discover or alsa?
On Oct 13, Wouter Verhelst [EMAIL PROTECTED] wrote: 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 hotplug. Sure, many people say silly things. hotplug is needed on most systems (think about USB devices), will probably become mandatory very soon (hint: udev) and needs anyway to support PCI hotplugging for systems with an hotplug PCI bus. Since it's here, is going to stay and does almost everything we need, automatically (it uses information provided by the kernel and does not need a database to be updated), I'd say we can as well use it for coldplugging. 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). ALSA does not loads modules anymore, the other packages you mentioned do not load device drivers and are not relevant in this discussion. Comments? Your proposals are (other than very vague) way too much complex and probably not even possible to implement. -- ciao, | Marco | [8536 arLPqUeErJ8NQ] signature.asc Description: Digital signature
Re: discover or alsa?
On Wed, 13 Oct 2004 13:43:01 +0200, Wouter Verhelst wrote: On Wed, Oct 13, 2004 at 10:51:46AM +0200, Marco d'Itri wrote: On Oct 13, Thomas Hood [EMAIL PROTECTED] 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 hotplug. [snip] The issue is that there are multiple auto-detection schemes in the 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. Comments? I think this is a situation where should push a particular implementation to standard. Just as we promote 'sysvinit' and have interoperability scripts for things like file-rc; if people want to use it. Once we've picked a standard one, I'm partial to hotplug myself since it seems to work well on both 2.4 and 2.6 kernels and I've found discover doesn't. The optional detection mechanism(s) can then come up with a programmatic interface similar to sysv-rc. Cheers, Anand -- linux.conf.au 2005 - http://lca2005.linux.org.au/ - Birthplace of Tux April 18th to 23rd - http://lca2005.linux.org.au/ - LINUX Canberra, Australia - http://lca2005.linux.org.au/ -Get bitten!
Re: discover or alsa?
On Wed, Oct 13, 2004 at 06:07:49PM +0200, Marco d'Itri wrote: On Oct 13, Wouter Verhelst [EMAIL PROTECTED] wrote: 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 hotplug. Sure, many people say silly things. hotplug is needed on most systems (think about USB devices), That's no argument for blatantly ignoring different implementations which perform similar things. will probably become mandatory very soon (hint: udev) and needs anyway to support PCI hotplugging for systems with an hotplug PCI bus. That doesn't have anything to do with coldplugging. Also, AFAIK, udev is far from the only /dev implementation in the kernel. I don't think it'll suddenly be mandatory. Since it's here, is going to stay and does almost everything we need, automatically (it uses information provided by the kernel and does not need a database to be updated), I'd say we can as well use it for coldplugging. Sure, I'm not contesting that. But there are other coldplugging implementations around. It's generally considered polite to respect different implementations. 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). ALSA does not loads modules anymore, ACPI. the other packages you mentioned do not load device drivers and are not relevant in this discussion. They load modules. This is a suggestion about managing how modules are loaded. Comments? Your proposals are (other than very vague) way too much complex and probably not even possible to implement. Of course they're vague. They're an initial idea. if want-module-load --package hotplug snd-ens1371 then modprobe es1371 fi want-module-load would check configuration files and 'exit 0' or 'exit 1' depending on whether it will allow hotplug to load the es1371 module. It would know that es1371 is an ALSA module for a PCI sound board, and would check whether hotplug would be allowed to load this module. The admin could say stuff such as discover oss forbid hotplug alsa allow Which would tell the system that discover is not to load any OSS modules, while it's okay for hotplug to load ALSA stuff. What's impossible about that? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: discover or alsa?
On Wed, Oct 13, 2004 at 07:26:32PM +0200, Wouter Verhelst wrote: [brown paper bag] if want-module-load --package hotplug snd-ens1371 then modprobe es1371 fi want-module-load would check configuration files and 'exit 0' or 'exit 1' depending on whether it will allow hotplug to load the es1371 module. It would know that es1371 is an ALSA module for a PCI sound board, and would check whether hotplug would be allowed to load this module. consistency is nice. s/es1371/snd-ens1371/g -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune
Re: discover or alsa? Solution proposal.
On Wed, 2004-10-13 at 10:30 +0200, Thomas Hood 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. Given these facts, what should the ALSA packaging team do? It seems that the alsa packages should Conflict with discover and discover1. I have a solution. Hotplug has many many great features. One such feature == /etc/hotplug/blacklist.d If ALSA is the preferred sound solution, then the alsa-base maintainer should present a list in hotplug with all of the traditional oss drivers names in a file called alsa-base. hotplug will indeed not load these files. Now, I propose, that since Discover v2 DOES indeed use modprobe to load its modules... alsa-base should have a similar list in something like /etc/discover/blacklist.d called alsa-base with the skip= done for all of the OSS modules. Now, this COULD be all addresses, in one way. Force discover and hotplug to honor a file in /etc/modprobe.d/alsa-base, which is currently there already but only has a few entries. Or just make sure they call modprobe vs anything else. If the entries where there for every OSS module, not just the ones there now (three redirections only) then it could be done with more ease. Sure I know it'd make the job of Jordi Mallach, Steve Kowalik, David B. Harris and Thomas Hood more painful... But, I'd even be willing to do the grunt work for the file if need be. It would seem to be a file with a bunch of CNP then edit. Of course, I am no programmer but understand programming from an Network and Systems Hardware Analyst POV. It is an idea, but will anyone think it a good one? -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: discover or alsa? Solution proposal.
On Oct 13, Greg Folkert [EMAIL PROTECTED] wrote: If ALSA is the preferred sound solution, then the alsa-base maintainer should present a list in hotplug with all of the traditional oss drivers names in a file called alsa-base. hotplug will indeed not load these files. Guess what? This is how it works... -- ciao, | Marco | [8542 dakmyZwg7lGh2] signature.asc Description: Digital signature
Re: discover or alsa?
On Oct 13, Wouter Verhelst [EMAIL PROTECTED] wrote: will probably become mandatory very soon (hint: udev) and needs anyway to support PCI hotplugging for systems with an hotplug PCI bus. That doesn't have anything to do with coldplugging. Also, AFAIK, udev is Sure it does. Why waste time duplicating the infrastructure? Also, programs like kudzu and discover need a database, while hotplug is automatically up to date to the installed kernel. This alone should be a major argument in its favour. far from the only /dev implementation in the kernel. I don't think it'll suddenly be mandatory. devfs is dead, deal with this. It has no future, and I expect it will be removed in the next two years. To learn why udev will probably become mandatory, read the threads about this in the debian-devel@ archive. 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). ALSA does not loads modules anymore, ACPI. The ACPI modules are not related to hotplug, at least currently. the other packages you mentioned do not load device drivers and are not relevant in this discussion. They load modules. This is a suggestion about managing how modules are loaded. non-device modules are not related to hotplug either. What's impossible about that? Impossible, not. Not needed and hard to deploy, yes. -- ciao, | Marco | [8541 conkbA9aSVJGU] signature.asc Description: Digital signature
Re: discover or alsa? Solution proposal.
On Wed, 2004-10-13 at 20:19 +0200, Marco d'Itri wrote: On Oct 13, Greg Folkert [EMAIL PROTECTED] wrote: If ALSA is the preferred sound solution, then the alsa-base maintainer should present a list in hotplug with all of the traditional oss drivers names in a file called alsa-base. hotplug will indeed not load these files. Guess what? This is how it works... Or at least SUPPOSED to work, when things aren't going the way it should, tells me not everyone is playing ball in the same park. I believe that kudzu and all them other hwdetect schemes out there should also use this method then. You need to have a choke point that everything else uses. All the stuff should be that way then. If it is, it doesn't feel that way yet. -- greg, [EMAIL PROTECTED] The technology that is Stronger, better, faster: Linux signature.asc Description: This is a digitally signed message part
Re: discover or alsa?
On Wed, Oct 13, 2004 at 08:18:45PM +0200, Marco d'Itri wrote: On Oct 13, Wouter Verhelst [EMAIL PROTECTED] wrote: will probably become mandatory very soon (hint: udev) and needs anyway to support PCI hotplugging for systems with an hotplug PCI bus. That doesn't have anything to do with coldplugging. Also, AFAIK, udev is Sure it does. Why waste time duplicating the infrastructure? Also, programs like kudzu and discover need a database, while hotplug is automatically up to date to the installed kernel. This alone should be a major argument in its favour. far from the only /dev implementation in the kernel. I don't think it'll suddenly be mandatory. devfs is dead, deal with this. I wasn't talking about DevFS specifically. Note that, when DevFS was accepted into mainline kernels, it was expected to be great and wonderful. Allow me to be a bit sceptical regarding udev -- especially given the .dev mess and related race conditions you mailed about a while ago. For the time being, I'm sticking to static /dev directories. It has kernel-side issues, but it's well-established, and it works. I expect many people will think the same way. Frankly, I'm not convinced udev is going to be as popular as you seem to suggest. It has no future, and I expect it will be removed in the next two years. So do I. To learn why udev will probably become mandatory, read the threads about this in the debian-devel@ archive. Care to provide me with a reference? 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). ALSA does not loads modules anymore, ACPI. The ACPI modules are not related to hotplug, at least currently. That can all change, at which point it'd suddenly have issues similar to the issues ALSA had in the past. Your point? the other packages you mentioned do not load device drivers and are not relevant in this discussion. They load modules. This is a suggestion about managing how modules are loaded. non-device modules are not related to hotplug either. Again, I was talking about more than just hotplug. Automagically configuring stuff is nice for desktop systems where those that are allowed physical access to the system do not necessary have root privileges. It isn't necessarily a good idea in, e.g., data centers. My point is that the proposed system would give a local admin the ability to manage modules over packages. Even if you think udev is the future and all the rest is crap, that doesn't have to mean everyone else agrees with you, or that it's even true. What's impossible about that? Impossible, not. Not needed and hard to deploy, yes. Frankly, that sorta summarizes my opinion about udev. It probably solves some issues at the kernel side of things, but from what I've seen, it sure looks ugly. Does that mean I should completely ignore it? -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune signature.asc Description: Digital signature
Re: discover or alsa?
On Wed, 13 Oct 2004 10:30:47 +0200, Thomas Hood 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. Well, no. Now discover1 (as yet unreleased) has support for an /etc/discover.d dir where you can have something akin to /etc/hotplug/blacklist.d/alsa-base. Of course, once that discover1 upload is made, the bug goes to the ALSA maintainers. I've removed the wontfix tag - I hope this conclusion is satisfactory to you. -- Joshua Kwan
Re: discover or alsa?
On Wed, 2004-10-13 at 11:12 +0200, Thomas Hood wrote: On Wed, 2004-10-13 at 10:57, Petter Reinholdtsen wrote: [Thomas Hood] Isn't this only a problem with discover1? I thought discover (v2) had a mechanism to detect if OSS or ALSA was used. If there is such a mechanism then it isn't working. It should. The current version of discover (v2) loads OSS drivers if the version of the kernel is = 2.4 and ALSA drivers if the version is = 2.6. There's currently no mechanism for telling the system to load ALSA drivers when running 2.4, but we intend to tackle that (and related configuration issues) in discover 2.1.x. The discover maintainers ended that discussion with a decision not to fix the bug in discover1. The bug _may_ be fixed in discover at some time in the future, presumably post-sarge. The remaining question is how alsa should deal with this situation. Conflict with discover[1]? Add a paragraph to the alsa-base README telling how to fix the problem by hand? Add code to the alsa initscript which rmmods OSS modules? I can't speak for discover1, as that is maintained by a different group now, but I suspect the reason this was marked wontfix was because discover1 has no built in mechanism for multiple versions of things, so there's no easy way for it to support both ALSA and OSS at the same time. discover2, on the other hand, has built in support for this. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ A door is what a dog is perpetually on the wrong side of. --Ogden Nash
Re: discover or alsa?
On Wed, 2004-10-13 at 10:51 +0200, Marco d'Itri wrote: On Oct 13, Thomas Hood [EMAIL PROTECTED] 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. That's funny, I've been saying the same thing about hotplug ever since the PCI stuff was turned on and boot time increased by 25%.. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ A door is what a dog is perpetually on the wrong side of. --Ogden Nash
Re: discover or alsa?
On Wednesday 13 October 2004 02:18 pm, Marco d'Itri wrote: udev will probably become mandatory At the moment, if your block devices aren't listed in /sys/block, udev seems to ignore them and to forbid you from creating them manually, at least in /dev. This made a CD writer inaccessible on a computer I was trying to fix recently until I accessed the CD drive via /proc. udev has some nice features, but until it works more reliably, I'd like it kept as far away from the standard install as possible. Daniel -- /--- Daniel Burrows [EMAIL PROTECTED] --\ |Is it too late to extricate myself| | from this plot line? | |Yes. -- Fluble | \- A duck! -- http://www.python.org / pgpJFls66LDpW.pgp Description: PGP signature
Re: discover or alsa?
On Wed, 2004-10-13 at 12:53 -0700, Joshua Kwan wrote: On Wed, 13 Oct 2004 10:30:47 +0200, Thomas Hood 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. Well, no. Now discover1 (as yet unreleased) has support for an /etc/discover.d dir where you can have something akin to /etc/hotplug/blacklist.d/alsa-base. Of course, once that discover1 upload is made, the bug goes to the ALSA maintainers. I will add this support to discover2 as well, since it currently suffers from the same problem as discover1 with respect to blacklisting modules. -- Ian Murdock 317-578-8882 (office) http://www.progeny.com/ http://ianmurdock.com/ A door is what a dog is perpetually on the wrong side of. --Ogden Nash
Re: discover or alsa?
On Wed, 2004-10-13 at 21:53, Joshua Kwan wrote: Well, no. Now discover1 (as yet unreleased) has support for an /etc/discover.d dir where you can have something akin to /etc/hotplug/blacklist.d/alsa-base. Of course, once that discover1 upload is made, the bug goes to the ALSA maintainers. I've removed the wontfix tag - I hope this conclusion is satisfactory to you. Very satisfactory, thanks. Will this feature be added to both discover1 and discover? BTW the wontfix tags is still there (#220616). -- Thomas
