Olof Johansson <o...@lixom.net> writes: > On Fri, Jan 29, 2010 at 04:26:56PM -0800, Kevin Hilman wrote: >> Update omap3_defconfig to work towards a minimal kernel by building >> most things as modules. Some drivers that cannot currently be built >> as modules and need to be fixed: > > Why? I introduced the omap3_defconfig with the intent of making it as > inclusive as possible, to catch build errors and build a common binary > for many platforms.
That's my goal too, as I regularly test the same kernel (in my case PM-enabled) on multiple OMAP3 boards. The only additional goal I have is to the kernel as small as possible and build most things as modules. I don't change what gets included in the build, I only moved some things from being built in to be built as modules. Doing 'make [uz]Image modules' will still catch all the build errors and build a common binary. > It's the only OMAP defconfig that Stephen Rothwell > builds as part of a linux-next cycle, and it will as such need to catch > build errors when others break ARM/OMAP. If linux-next is not also building modules for OMAP, we need to request that it does. It does so for other platforms. > >> - MMC: platform code uses MMC core regulator functions directly >> - ASoC: drivers call omap_ctrl_[read|write] directly >> >> In addition some additional changes: >> >> - use new SLUB allocator instead of SLAB (increased debugability) >> - compile with PREEMPT enabled by default >> - disable OABI_COMPAT. We should not pretend to support this IMHO >> - disable CPUfreq: not yet supported in mainline >> - disable PM_DEBUG_VERBOSE >> - enable fb/DSS2 as modules >> - disable Kprobes >> >> zImage size comparison >> before: 3160272 >> after: 2610108 >> >> Some ideas for reducing this further: >> - fix MMC and ASoC, then build those as modules >> - disable all the kernel debug features >> - convert MTD and all flash fs to modules >> >> Then, we should have platform specific initramfs configs so rootfs >> from flash, MMC, etc. could be done using modules in initramfs. > > I'm all for allowing an "allmodconfig" kernel to be booted, and it's good > to clear up some of these dependencies. But I'd prefer if it wasn't done > under omap3_defconfig. :) Why not? Building a monolithic kernel for multiple boards leads to lots of wasted memory and slower boot time. At a minimum, I'd at least like to get to "build everything except possible root filesystems as modules" kernel. Kevin -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
