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-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
