OK, after digging around, I've learned some things. modprobe.conf doesn't list the modules to be loaded (did it at one point? I don't know. But it doesn't now), just the rules for things like naming/aliasing modules, local dependencies, substituting one module for another, etc. If I'm reading the docs right, that is. It seems mostly for manually running modprobe, and tweaking its behaviour so that in general, whether modules are automatically or manually loaded, it can be made easier to understand; or to compensate for local fringe case behaviour. Either way, not really helpful.
I'd thought in the past the kernel had a list of all modules it loaded on boot. Either this isn't the case anymore, or I've been mistaken all these years. *shrug* Whatever. The kernel does the loading, talks to udev about it, and on the upside, it doesn't say anything about udev freaking out and crashing the system if the kernel can't find the module it wants. But, this could make my life a little harder in the kernel paring script if it turns out modinst needs to interface with udev to work properly. Maybe there's a way to wedge modinst in between the kernel, modprobe, and udev? This is sounding harder and harder to do. It can't be impossible, but I should probably apologize in advance to my fiancee for the frustrated screaming he'll have to listen to. ;)
Arch has an option in rc.conf to disable udev autoloading on boot, and specify which modules to load. I'm getting ready to play around with that in a vbox image. One other thing I have going for me is, servers usually don't have a lot of hotplugging going on, or if they do (ie, scsi disks) it's with identical parts. Unlike a desktop with random devices getting plugged in and unplugged, which the kernel has to cope with.
Trash80's idea of writing our own hal and udev (pykal and pydev) is sounding really good right now.
No comments:
Post a Comment