K.Mandla's blog of Linux experiences

Module parameters from rc.conf in Arch

I have an oddball little tip this time, something that will be either a godsend or something you can conveniently forget. If you’re an Arch user and you find yourself needing to pass parameters to a module, you can do that from within the rc.conf file, instead of relying on /etc/modprobe.d/modules.conf.

For example, forcing an 800×600, 16bpp framebuffer resolution at 60Mhz vertical sync rate with the tridentfb module will require a command like this.

modprobe tridentfb mode=800x600-16@60

Ordinarily I would stuff something like that in /etc/modprobe.d/modules.conf, but I realized the other day that this line from rc.conf will do the same thing.

MODULES=("tridentfb mode=800x600-16@60")

Encapsulating it in quotes allows Arch to handle the entire segment — module and parameters — without a hiccup. You can add other modules as you normally would or blacklist them with the exclamation mark prefix too, and they’ll work just fine.

Like I said, this is something slightly esoteric and might never be of use to you. (It might also be that this is common knowledge and that I’m repeating something everybody already knows. It wouldn’t be the first time. … :oops::roll: )

On the other hand, if you can pass parameters to a module like this, it means you can rely on rc.conf instead of farming out to other configuration files. And of course, one of the beauties of Arch is the fact that 90 percent of the configuration takes place in that one file. Might as well keep it there. ;)

For some reason I doubt this is intended behavior… given the quality of their wiki, Arch has very few undocumented features. :) I still think this is a clever little hack though!

It works because /etc/rc.sysinit executes/sbin/modprobe $mod
for each entry in MODULES instead of /sbin/modprobe "$mod"
so bash performs word splitting on the parameter expansion of $mod.

The caveat that should be mentioned is that this will only apply to the “Loading Modules” step at boot time. If you later remove and re-load a module with modprobe, any parameters you set here won’t take. This is probably why the /etc/modprobe.d method is recommended… it’s more likely always to work the way you expect (i.e. “the right way”), and it’s guaranteed not to break if the devs change the above-mentioned rc.sysinit line.

Cool idea though! If you like it, you could probably even modify the initscripts to autogenerate a custom modprobe.d file from these at bootup… submit a patch, who knows?

That sounds like a good project for a talented Archer. I will probably surrender that idea to someone else though, because I don’t trust my infantile coding skills to work beyond the confines of my own home. :oops::)