Mike (mwester) wrote: > But I'm lazy. And that means that if I *also* had to package up a > tarball of all the modules, copy them up to the rootfs, make sure I have > space, untar them, remember to delete them when done, just so I could > boot that kernel to do that test, well, it's less likely that I'm going > to find time to do that.
I understand your pain :-) That's precisely why I hate modules. Independent from what atrocities are being committed with EXTRAVERSION, this problem would be largely avoided if you could just make a monolithic kernel, and ignore whatever modules are on the system. (This would put the system into a state where the real kernel isn't what the package system thinks it is. However, the next update would return the system from that experimental state to normality.) That's in fact how most of us operate anyway: make a new kernel, replace the old, boot, and hope the modules won't act up. The good thing is that it almost always works ;-) Where this wouldn't help are those few cases where a problem only appears when using modules, but not in the monolithic kernel. Another case where this doesn't work is when some functionality requires the use of modules, e.g., because they're abused as a selection mechanism (e.g., USB gadgets) or because some user space framework insists on using them. I think for the developers and users involved in fast-cycle testing, a monolithic kernel is the best choice, precisely because it keeps the number of moving parts to its minimum. So if we can get rid of those few obstacles that prevent a monolothic kernel from working satisfactorily, we'd have something that's good for developers and that still lets users who never or only rarely get involved in kernel development or testing still benefit from whatever benefits modules give them. (Obviously, if we make the monolithic kernel work better, these benefits will dimisish :-) So far, the following party spoilers have been mentioned: - USB gadget selection - long start-up of WLAN Any others ? - Werner _______________________________________________ devel mailing list [email protected] https://lists.openmoko.org/mailman/listinfo/devel
