> > My main bone of contention was the statement that there was no reason for > > not building something as a module. There is a case for building drivers > > into the kernel. Whether it is the best choice is something that depends > > on what one is trying to achieve. > > As Felipe wrote, it is easy to reconfigure a module to be build in than > it is to get a build in and have it to be compilable and usable as > module. Developing a module gives you for free the builtin case. > The other way is not always true. Agreed. That is correct. > Your case of "let's veryfy all the modules at once by converting them to > built-ins" is more the exception than the rule. 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. > > > And on top of that, having modules allows to makes it simpler to address > > > in one go different boards and subarchitectures. > > > > I'm afraid I don't understand. How would having a driver as a module or > > built-in make a difference when targetting different boards? > > I can do just one build and use the same binary to do the deployment to > different boards. This can still be done if you have everything built-in. Is there any reason for such a all-built-in kernel not to work across boards? 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. > That's the direction the kernel is currently going to, with code that > probes for OMAP version and uses the appropriate register addresses. > > The bootloader can pass the board type as option. This can be done with a modular kernel as well as with an all-built-in kernel. 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. 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. - Anand -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
