I think the "Kernel Hacking" menu has gotten a bit out of hand. It is over 120 lines long on my system with everything enabled and options are scattered around it haphazardly. http://sr71.net/~dave/linux/kconfig-horror.png Let's try to introduce some sanity. I believe the risk of a series like this is pretty low, so I'd like to see these make it in to 3.8 if there are no major objections. This set stands on its own, but there is plenty of room for follow-up patches. The arch-specific debug options still end up getting stuck in the top-level "kernel hacking" menu. OPTIMIZE_INLINING, for instance, could obviously go in to the "compiler options" menu, but the fact that it is defined in arch/ in a separate Kconfig file keeps it on its own. Any thoughts on how we could address this going forward? 1. Define all arch-specific debugging options in lib/Kconfig.debug Have the architectures 'select' them. 2. Introduce some Kconfig language changes that allow menu position to be specified independently of where the "config" text occurs, like an "appears_in": config DEBUG_INFO bool "Compile the kernel with debug info" depends on DEBUG_KERNEL appears_in "Kernel Hacking/Compiler Options" ... or, perhaps have a directive that says "do not place the menu item now, I will specify a place for it later" 3. Stick all of the arch-specific kernel hacking options under an arch-specific submenu, despite if they would fit better in the "Memory Debugging" or compiler menu. -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
