Proper way to autoload modules (/etc/rc.modules)?

[Pete Zaitcev]

On Fri, 08 Apr 2005 00:10:40 -0400 pjones <pjones at redhat.com> wrote:

> Ok, that one example isn't completely perfect, so here's a better one.
> If I load usb_storage before sd_mod, the iRiver plugged into my usb port
> is going to be sda, and the drive plugged into my scsi bus will be sdb,
> right?
> 
> And if I load them in the opposite order?

I have an easy answer to this one: "use ub". Mwua hah hah hah ha!
But in all seriousness, it's a problem which has nothing to do with
module loading order. Consider a USB flash key and iRiver instead, one
of them is /dev/uba and another is /dev/ubb. Now, which is which?
This is very interesting and is something our intrepid hotplug and
HAL crew has to approach, but it has nothing to do with /etc/rc.modules
and so I'd like to see some other example.

I'm sending you round to gather examples because while it's intuitively
obvious that /etc/rc.modules is useful, it really has no reason to exist.
Yes, we all used it at one time or other, as a shortcut while a proper
solution was not available. I think I have a box which loads vt8231
from /etc/rc.modules myself. That's all fine, and perhaps we ought to
keep it around forever. But making it more legitimate with /etc/modules.d
or some such has no reason.

> When there are enough files in rc5.d that I often have to choose between
> using the service name as part of the sort or renumbering other
> services, I call that cluttered.  And we're already at that point.

That's probably something important, but I'd rather see it done
differently. Fundamentally, you cannot farm out every "class" or
"type" of script according to vague criteria into its own directory.
You do not have enough kernel modules to make a sizeable dent in the
clutter. :-) The right solution is to create some sort of radix ordering
in rcN.d which allows to wedge infinite number of new scripts between
any other scripts (well, I think so far. I also saw curious replacements
for init scripts with unnumbered scripts, a make-like dependency DAG
and things like that. Compatibility is a problem, however).

-- Pete