On Fri, 08 Apr 2005 00:10:40 -0400 pjones <pjones@xxxxxxxxxx> 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
