> > And like you said, if the defconfig is all modular (or all built-in) > > the user/manufacturer/hacker can always change it later. Although > > I defend that Reference Boards' defconfigs should be as modular > > as possible. > > I totally agree: furthermore testing power features is damn easier if we > can bisect the modules and zero on the offending driver. I agree too. No contest. On the other hand, the easiest way to find that something is broken is if it is built-in in the kernel. Else, you could easily overlook some module that you never loaded because it wasn't an area you worked on. For a recent example of this, it is not very likely that I would have found that the display driver was broken because if it were a module, I would rarely load it. I caught it only because it was preventing a defconfig kernel from booting. We do have an "allmodconfig" target. How about using that when you want to bisect and find the broken driver? 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. > > 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? - 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
