On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen <teg@xxxxxxx> wrote: > Thanks for your Oon-ee. > > Sun, May 29, 2011 at 10:53 AM, Oon-Ee Ng <ngoonee.talk@xxxxxxxxx> wrote: >> On Sat, May 28, 2011 at 9:16 PM, Tom Gundersen <teg@xxxxxxx> wrote: >> <snip> >>> rc.conf - MODULES(!mod1, !mod2): blacklisting modules in the modules >>> array will no longer have any effect. modprobe already provides two >>> different ways of preventing modules from being loaded, so this is >>> just a matter of updating some configuration files. To blacklist >>> modules, add a new .conf file to /etc/modprobe.d/ with the contents >>> >>> blacklist mod1 >>> blacklist mod2 >> <snip> >> >> This seems a regression of current rc.conf behaviour (in essence, >> moves another configuration back to upstream default which was >> previously in rc.conf). Is there any good reason to keep current >> behaviour (perhaps an Arch-specific udev rule which parses MODULES for >> blacklisting?) > > I have not found any uses of the MODULES array like you describe (if > they exist they should be considered bugs though, the MODULES array > was not meant to be used in this way). However, if anyone knows of > any, then please let me know. > > Cheers, > > Tom > Glad to oblige, here's my current MODULES:- MODULES=(!phc-intel acpi_cpufreq vboxdrv vboxnetflt loop fuse !net-pf-10 !snd_pcsp uinput !pcspkr coretemp) When I was testing out undervolting I used the phc-intel blacklist to prevent it loading (otherwise it would automatically load even if not listed). Don't use it anymore, but its a use-case. The blacklists of the other three I got from the old old Beginner's Guide when I first set up (couple of years back) but at least snd_pcsp and pcspkr are still recommended to be blacklisted here https://wiki.archlinux.org/index.php/Disable_PC_Speaker_Beep The purpose is simply to disable those annoying speaker beeps. Since computers normally come with sound cards nowadays, why would we want to hear polyphonic beeps which even our handphones and microwave ovens don't use anymore =). As I said, when the change happens I'd personally just write the custom udev rules and forget about them, no big deal.
