linux-kernel - Re: [PATCH][RFC] Restructure Device Driver menu entries

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 for Android: free password hash cracker in your pocket

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

Date:	Wed, 6 Dec 2006 11:54:00 -0800
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	"Robert P. J. Day" <rpjday@...dspring.com>
Cc:	Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH][RFC] Restructure Device Driver menu entries

On Wed, 6 Dec 2006 09:33:46 -0500 (EST) Robert P. J. Day wrote:

> 
>   This is a *proposed* restructuring of the DD menu so that one can
> see and select/de-select entire submenus without having to enter each
> submenu.    It's also immediately obvious visually which submenus are
> currently active.
> 
>   Based on Randy Dunlap's earlier suggestion, it uses the kbuild
> "menuconfig" feature.  I changed only those sub-entries that matched
> an obvious pattern (that is, selectable in their entirety).  If there
> was *anything* slightly different about that sub-entry, I left it
> alone.  (That doesn't mean that those sub-entries can't be similarly
> tweaked with a minimum of effort, I was just keeping it simple for
> now.)
> 
>   Finally, if this structure is used, there's still a good deal of
> cleanup that can be done on each Kconfig file.  For example, if most
> of the mtd Kconfig file is now surrounded by
> 
>   if MTD
>   ...
>   endif
> 
> then each internal entry no longer has to include any variation of
> 
>   depends on MTD
> 
> but, for the time being, I left the individual config entries alone
> and just changed the top-level structure of each Kconfig file that was
> appropriate, just to get some feedback.
> 
>   Thoughts on this approach?

Looks like InfiniBand support wasn't converted to use the
menuconfig keyword?  Now its menu shows up at an odd location
in xconfig.  (Please test changes with menuconfig, xconfig, &
gconfig.)

Otherwise looks good to me.


> diff --git a/drivers/infiniband/Kconfig b/drivers/infiniband/Kconfig
> index 9edface..25454e8 100644
> --- a/drivers/infiniband/Kconfig
> +++ b/drivers/infiniband/Kconfig
> @@ -1,13 +1,13 @@
> -menu "InfiniBand support"
> -
>  config INFINIBAND
> -	depends on PCI || BROKEN
>  	tristate "InfiniBand support"
> +	depends on PCI || BROKEN
>  	---help---
>  	  Core support for InfiniBand (IB).  Make sure to also select
>  	  any protocols you wish to use as well as drivers for your
>  	  InfiniBand hardware.
> 
> +if INFINIBAND
> +
>  config INFINIBAND_USER_MAD
>  	tristate "InfiniBand userspace MAD support"
>  	depends on INFINIBAND
> @@ -45,4 +45,4 @@ source "drivers/infiniband/ulp/srp/Kconf
> 
>  source "drivers/infiniband/ulp/iser/Kconfig"
> 
> -endmenu
> +endif

---
~Randy
-
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/