* Gadiyar, Anand <[EMAIL PROTECTED]> [080626 11:33]: > > > That wasn't what I said or meant. What I did want to bring out was that > > > having > > > something built-in might give it more exposure to test by someone who > > > wasn't > > > actively working on that area. And most bugs are caught by people other > > > than > > > the active developers. > > > > Not really, another usecase for modular kernel is that we don't wanna > > add e.g. tea (radio) driver for n810 cuz it doesn't have that chip. > > With modular kernel with proper MODULE_ALIAS() and udev, you just > > flash the same kernel and modules in both n800 and n810 and tea driver > > would only be probed in n800. > > > > I think this is what Igor meant when we said about validation across > > boards. > > Ok. Fair enough. Point taken. > > > > > At first glance to your email, I thought you had a valid point here. > > > Thinking a > > > little more, I think your point is valid only if you had a module that > > > should not > > > be loaded on a particular board. In such a case, you would anyway want to > > > fix that > > > module. > > > > Or you rely on udev rules and keep the main kernel code smaller. > > > > > Yes, having a modular kernel is useful. And it is probably the way to go. > > > But please > > > don't tell me that you can't do the same things with almost everything > > > built-in. > > > > some stuff you really can't. If your mmc driver get stuck somewhere, you > > can't modprobe -r -f omap_hsmmc and restart your work with a built-in > > mmc driver. With modular kernel, we really can do it: forcefully remove > > the driver and reset the controller, this would give us oportunity to > > analyze logs and try again by reloading the module. > > > > With a built-in kernel, the only way out is reboot. > > Agreed. > > > > The 2430 defconfig has almost everything modular, while the 3430 > > > defconfig doesn't. > > > I propose we start a separate defconfig for the modular case or use > > > allmodconfig. > > > Maybe even have this as the defconfig for the multi-omap kernel. If we > > > keep the > > > individual defconfigs as a nearly all-built-in case, we can still get the > > > best of > > > both worlds. > > > > The thins is that normaly you'd have udev running anyways, and it would > > automatically load modules based on /sys and correct MODULE_ALIAS() > > and that's already another thing to test that can't be tested with built-in > > modules. > > > > We know that several omap drivers are missing MODULE_ALIAS() and recently > > I've > > added it to all twl4030 drivers for that purpose. > > > > We can now rely that udev will correctly load the necessary module when we > > need it. And when I stated that there's no reason for not building > > everything as dynamic module for omaps, I was considering that we have > > enough memory in our boards and generaly developers will use NFS > > root file system anyways. > > > > I think this discussion is now way too long for something really > > simple: For development purposes on SDPs, dynamic linked modules > > can increase the development cycle by decreasing the amount of > > build/flash/reboot cycles. > > Okay. End of discussion. :)
Pushing Jouni's patch to make MMC a module today :) Tony -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
