[arch-dev-public] blacklisting issue, perhaps initscripts or kernel 3.0 related
Hi guys, https://bugs.archlinux.org/task/25308 If I blacklist a module in modprobe.d directory and add it to MODULES= array in rc.conf the module is not loaded anymore. Is there a reason that this is not working anymore? Thanks for your help greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On 07/31/2011 09:46 PM, Tobias Powalowski wrote:
Hi guys, https://bugs.archlinux.org/task/25308 If I blacklist a module in modprobe.d directory and add it to MODULES= array in rc.conf the module is not loaded anymore. Is there a reason that this is not working anymore?
Thanks for your help greetings tpowa
why would you want to have in blacklist a module that you want to load explicitly in MODULES? -- Ionuț
Am 31.07.2011 20:49, schrieb Ionut Biru:
On 07/31/2011 09:46 PM, Tobias Powalowski wrote:
Hi guys, https://bugs.archlinux.org/task/25308 If I blacklist a module in modprobe.d directory and add it to MODULES= array in rc.conf the module is not loaded anymore. Is there a reason that this is not working anymore?
Thanks for your help greetings tpowa
why would you want to have in blacklist a module that you want to load explicitly in MODULES?
To explain it a bit better: Arch always had the possibility to load modules in a certain order by using the MODULES= array in rc.conf. Why would this be useful? In the past people had more than one soundcard in the pc, the problem by autoloading modules with udev, could change the order of this sounddevices. This is not that much a problem anymore, modern systems mostly have only one soundcard installed. If you have 2 or more network cards in your pc this might also happen, which is a more common scenario. Yes you can use udev for assigning the network names, I preferred the blacklist way with loading it manually from the MODULES= array. If more devs say, we don't need the feature of blacklisting and loading afterwards in MODULES= anymore i'm fine with that. But we will loose the ability to explicitly load modules in a certain order forever. UDEV is good in autoloading modules, but sometimes it might fail and then you have no good way to change that behaviour. Any other opinions on this? Thanks greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
Am 01.08.2011 09:30, schrieb Tobias Powalowski:
To explain it a bit better: Arch always had the possibility to load modules in a certain order by using the MODULES= array in rc.conf.
Preservation of order has not been working for several initscripts releases.
Am 01.08.2011 09:44, schrieb Thomas Bächler:
Am 01.08.2011 09:30, schrieb Tobias Powalowski:
To explain it a bit better: Arch always had the possibility to load modules in a certain order by using the MODULES= array in rc.conf.
Preservation of order has not been working for several initscripts releases.
Ok talked to Thomas, seems there will be no chance to get the old stuff back. No problem i'll remove it from archboot media and probably replace it with udev rules. Media 2011.08 will contain the changes. greetings tpowa -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) http://www.archlinux.org tpowa@archlinux.org
On Mon, Aug 1, 2011 at 2:44 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.08.2011 09:30, schrieb Tobias Powalowski:
To explain it a bit better: Arch always had the possibility to load modules in a certain order by using the MODULES= array in rc.conf.
Preservation of order has not been working for several initscripts releases.
Order preservation is doable via modprobe configs. See /etc/modprobe.d/usb-load-ehci-first.conf for an example.
Am 01.08.2011 16:48, schrieb Aaron Griffin:
On Mon, Aug 1, 2011 at 2:44 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.08.2011 09:30, schrieb Tobias Powalowski:
To explain it a bit better: Arch always had the possibility to load modules in a certain order by using the MODULES= array in rc.conf.
Preservation of order has not been working for several initscripts releases.
Order preservation is doable via modprobe configs. See /etc/modprobe.d/usb-load-ehci-first.conf for an example.
Indeed, but it is not pretty.
On Mon, Aug 01, 2011 at 05:19:11PM +0200, Thomas Bächler wrote:
Am 01.08.2011 16:48, schrieb Aaron Griffin:
On Mon, Aug 1, 2011 at 2:44 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Am 01.08.2011 09:30, schrieb Tobias Powalowski:
To explain it a bit better: Arch always had the possibility to load modules in a certain order by using the MODULES= array in rc.conf.
Preservation of order has not been working for several initscripts releases.
Order preservation is doable via modprobe configs. See /etc/modprobe.d/usb-load-ehci-first.conf for an example.
Indeed, but it is not pretty.
It's also not recommended by upstream, as per modprobe.conf(5). We shouldn't make any guarantees about module load order. What's the problem we're trying to solve with this juggling? Is this bandaiding and issue that should be taken upstream to the kernel folk? Or, is this some pre-emptive attack against hardware being claimed by the wrong module, in which case we should be leaving it up the user to figure out which module they want to use... dave
Am 01.08.2011 17:23, schrieb Dave Reisner:
It's also not recommended by upstream, as per modprobe.conf(5). We shouldn't make any guarantees about module load order. What's the problem we're trying to solve with this juggling? Is this bandaiding and issue that should be taken upstream to the kernel folk? Or, is this some pre-emptive attack against hardware being claimed by the wrong module, in which case we should be leaving it up the user to figure out which module they want to use...
Apparently, it is recommended upstream to load ehci before uhci or ohci (which userspace cannot safely guarantee) and actual bugs are caused if we don't. I don't like this, but we couldn't think of another solution.
On Mon, Aug 01, 2011 at 05:37:56PM +0200, Thomas Bächler wrote:
Am 01.08.2011 17:23, schrieb Dave Reisner:
It's also not recommended by upstream, as per modprobe.conf(5). We shouldn't make any guarantees about module load order. What's the problem we're trying to solve with this juggling? Is this bandaiding and issue that should be taken upstream to the kernel folk? Or, is this some pre-emptive attack against hardware being claimed by the wrong module, in which case we should be leaving it up the user to figure out which module they want to use...
Apparently, it is recommended upstream to load ehci before uhci or ohci (which userspace cannot safely guarantee) and actual bugs are caused if we don't. I don't like this, but we couldn't think of another solution.
Oh, absolutely... https://bugzilla.redhat.com/show_bug.cgi?id=464908 https://bugzilla.redhat.com/show_bug.cgi?id=154008 https://bugs.archlinux.org/task/12009 and every distro does this, similar to the way we do it. This seems like an edge case though -- you might want ohci _and_ ehci for different devices. On the other hand, you definitely don't want (incoming contrived example) b43 being loaded for your wifi card that can use brcmsmac instead. There's no use case for both being loaded. In the case of sound modules, we shouldn't enforce order -- leave it up to the user to order the devices via modprobe config. dave
participants (5)
-
Aaron Griffin
-
Dave Reisner
-
Ionut Biru
-
Thomas Bächler
-
Tobias Powalowski