On Sun, May 29, 2011 at 6:31 PM, Oon-Ee Ng wrote:

On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen wrote:

...

Thanks for your Oon-ee.

Sun, May 29, 2011 at 10:53 AM, Oon-Ee Ng wrote:

...

On Sat, May 28, 2011 at 9:16 PM, Tom Gundersen 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.

Ah, and I just remembered net-pf-10 was to disable IPv6 (I think). But in that case, the wiki has been updated with the new methods of doing so.

On Sun, May 29, 2011 at 12:44 PM, Casey Peter wrote:

Also !usblp  for those of us with USB printer issues.  (especially HP usb inkjets)

Yup, blacklist it in /etc/modprobe.d (we should probably fix this once and for all, I believe other distro's simply removed this module, but haven't had time to look into it). On my computer the module is not loaded for some reason (I have a HP usb laserjet)... -t

Am 29.05.2011 12:52, schrieb Tom Gundersen:

On Sun, May 29, 2011 at 12:44 PM, Casey Peter wrote:

...

Also !usblp for those of us with USB printer issues. (especially HP usb inkjets)

Yup, blacklist it in /etc/modprobe.d (we should probably fix this once and for all, I believe other distro's simply removed this module, but haven't had time to look into it). On my computer the module is not loaded for some reason (I have a HP usb laserjet)...

-t

Removing the module isn't a good idea, as some applications still need it. For example escputil, which is shipped with gutenprint, needs usblp to read the ink levels from some EPSON printers. So only blacklisting it by default seems to be the better way. -- Regards, Richard Schütz

On Sun, May 29, 2011 at 12:32 PM, Oon-Ee Ng wrote:

On Sun, May 29, 2011 at 6:31 PM, Oon-Ee Ng wrote:

...

On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen wrote:

...

Thanks for your Oon-ee.

Sun, May 29, 2011 at 10:53 AM, Oon-Ee Ng wrote:

...

On Sat, May 28, 2011 at 9:16 PM, Tom Gundersen 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.

Ah, and I just remembered net-pf-10 was to disable IPv6 (I think). But in that case, the wiki has been updated with the new methods of doing so.

This usecase of disabling features you don't need is exactly what "blacklist" is for, so it should work as expected to create a file in /etc/modprobe.d: blacklist pcspkr blacklist phc_intel Note that some of the blacklisting you are doing might be obsolete by the next udev release: I will remove some old arch-specific rules so that pcspkr will become opt-in rather than opt-out in many (all?) cases. snd_pcsp is not included in the standard arch kernel (AFAICT), I don't know its history though, so don't know what happened to it. Cheers, Tom

On Sun, May 29, 2011 at 12:45 PM, Auguste Pop wrote:

On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen wrote:

...

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.

i'll really like to know what is the "meant" way of using MODULES array in rc.conf?

in rc.conf shipped with initscripts 2011.05.2-1, it is stated clearly: "MODULES: Modules to load at boot-up. Prefix with a ! to blacklist." and all of a sudden, prefixing modules with ! in MODULES array to blacklist the module at boot is considered improper use?

No. I was saying that only load-modules.sh/initscripts should parse the MODULES array directly (Oon-ee was suggesting that udev rules might rely on the MODULES array). Once we make this change, then blacklisting in rc.conf will become unsupported and we would of course update the comment and make an announcement. It should be replaced by a native modprobe configuration file (see my previous email or "man modprobe.conf"). Cheers, Tom

I recently did a fresh install and noticed a ton of modules prefixed with ! in rc.conf by default. Not at the box currently but it was 5-7 modules listed. This will have to be changed. Also, this functionality has worked the same way for the entire time that I've used Arch. That is since 2003 and prefixing with ! was used to blacklist way back then. This change will break a lot of configurations.

On Sun, May 29, 2011 at 5:03 PM, Meyithi wrote:

If that happened then you used the Archboot install media with it's hwdetect consistent device ordering option.  Archboot isn't official install media and I suspect that feature will have to be reworked because of the udev changes anyway.

Thanks for the pointer. I was not aware of this behavior. I looked at the wikipage of archboot and I don't think this feature can work reliably: modprobe does not promise to insert the modules in our MODULES array in the order they are listed. To get persistent ordering of devices one should use udev rules (though in most cases this is not needed). Cheers, Tom

On Sunday 29 of May 2011 13:56:15 Tom Gundersen wrote:

On Sun, May 29, 2011 at 12:45 PM, Auguste Pop wrote:

...

On Sun, May 29, 2011 at 6:18 PM, Tom Gundersen wrote:

...

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.

i'll really like to know what is the "meant" way of using MODULES array in rc.conf?

in rc.conf shipped with initscripts 2011.05.2-1, it is stated clearly: "MODULES: Modules to load at boot-up. Prefix with a ! to blacklist." and all of a sudden, prefixing modules with ! in MODULES array to blacklist the module at boot is considered improper use?

No. I was saying that only load-modules.sh/initscripts should parse the MODULES array directly (Oon-ee was suggesting that udev rules might rely on the MODULES array).

Once we make this change, then blacklisting in rc.conf will become unsupported and we would of course update the comment and make an announcement. It should be replaced by a native modprobe configuration file (see my previous email or "man modprobe.conf").

I seem to remember that the point of rc.conf was to configure system in one place. Looks like the politics are changing. Networking, hardwareclock, now modules. Locale next ? Regards,

On Mon, May 30, 2011 at 2:50 AM, Tom Gundersen wrote:

2011/5/29 Vytautas Stankevičius :

...

I seem to remember that the point of rc.conf was to configure system in one place. Looks like the politics are changing.

rc.conf is the one place for all Arch-specific settings. As you know /etc is full of config files owned by different packages, rc.conf is for the stuff that does not belong anywhere else.

Thank you, this is a very clear statement, and applies further than just to this topic (I'm thinking systemd and the possible resulting deprecation of our DAEMONS array in rc.conf). Wasn't aware of 'Arch-specific settings' in this context, even though it makes perfect sense once mentioned.