[PATCH 0/7] Put "Kernel hacking" Kconfig menu on a diet

[Dave Hansen]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/