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]
Message-Id: <20121217182206.91AA150A@kernel.stglabs.ibm.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ