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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 17 Dec 2012 13:22:06 -0500
From:	Dave Hansen <dave@...ux.vnet.ibm.com>
To:	torvalds@...ux-foundation.org
Cc:	linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org,
	linux-arch@...r.kernel.org, Dave Hansen <dave@...ux.vnet.ibm.com>
Subject: [PATCH 0/7] Put "Kernel hacking" Kconfig menu on a diet

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