Hey, On Tue, Jan 15, 2013 at 07:37:42PM -0800, Linus Torvalds wrote: > I do want the same user-visible semantics, so it's not some one-liner. > > The compiled-in elevator would be easy enough to handle in the Kconfig > file (maybe we do already, I didn't even bother to check). The real > problem is the "chosen_elevator" one, which is dynamic with the kernel > command line. And we could handle that one by just trying to load the > module early (but exactly _when_?) and then instead of looking things > up by name, just keep a pointer to the default elevator around. > > But no, it's not just some trivial one-liner. Especially the question > about "when to try to load the module that is given on the kernel > command line" is not trivial. Do we require that the module is in the > initrd and loadable basically immediate at boot? Do we try again after > switching the root filesystem? Things like that.. If the current user-visible semantics is defined as "the kernel shall try to load the default iosched if not already available on each block device discovery", nothing can be changed ever, but I'm not sure it needs to be pushed that far. As Arjan suggested, trying to load the default modules right after the initial rootfs mount could be an acceptable compromise and it would be really nice (for both code sanity and avoiding future problems) to be able to declare module loading nested inside async unspported. Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
