mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH] Use menuconfig objects - Fusion
       [not found] <200705102317.l4ANHrUC001117@shell0.pdx.osdl.net>
@ 2007-07-21 18:56 ` Jan Engelhardt
  2007-07-21 19:05   ` Robert P. J. Day
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Engelhardt @ 2007-07-21 18:56 UTC (permalink / raw)
  To: akpm; +Cc: Eric.Moore, Linux Kernel Mailing List


On May 10 2007 16:17, akpm@linux-foundation.org wrote:
>The patch titled
>     Use menuconfig objects II - fusion
>has been removed from the -mm tree.  Its filename was
>     use-menuconfig-objects-ii-fusion.patch
>
>This patch was dropped because it broke

Here is an updated version.

Thanks,
	Jan
===


Change Kconfig objects from "menu, config" into "menuconfig" so
that the user can disable the whole feature without having to
enter the menu first.

Signed-off-by: Jan Engelhardt <jengelh@gmx.de>

---
 drivers/message/fusion/Kconfig |   19 ++++++++++---------
 1 file changed, 10 insertions(+), 9 deletions(-)

Index: linux-2.6.23/drivers/message/fusion/Kconfig
===================================================================
--- linux-2.6.23.orig/drivers/message/fusion/Kconfig
+++ linux-2.6.23/drivers/message/fusion/Kconfig
@@ -1,15 +1,19 @@
 
-menu "Fusion MPT device support"
+menuconfig FUSION
+	bool "Fusion MPT device support"
 	depends on PCI
+	---help---
+	Say Y here to get to see options for Fusion Message
+	Passing Technology (MPT) drivers.
+	This option alone does not add any kernel code.
+
+	If you say N, all options in this submenu will be skipped and disabled.
 
-config FUSION
-	bool
-	default n
+if FUSION
 
 config FUSION_SPI
 	tristate "Fusion MPT ScsiHost drivers for SPI"
 	depends on PCI && SCSI
-	select FUSION
 	select SCSI_SPI_ATTRS
 	---help---
 	  SCSI HOST support for a parallel SCSI host adapters.
@@ -24,7 +28,6 @@ config FUSION_SPI
 config FUSION_FC
 	tristate "Fusion MPT ScsiHost drivers for FC"
 	depends on PCI && SCSI
-	select FUSION
 	select SCSI_FC_ATTRS
 	---help---
 	  SCSI HOST support for a Fiber Channel host adapters.
@@ -41,7 +44,6 @@ config FUSION_FC
 config FUSION_SAS
 	tristate "Fusion MPT ScsiHost drivers for SAS"
 	depends on PCI && SCSI
- 	select FUSION
 	select SCSI_SAS_ATTRS
 	---help---
 	  SCSI HOST support for a SAS host adapters.
@@ -55,7 +57,6 @@ config FUSION_SAS
 
 config FUSION_MAX_SGE
 	int "Maximum number of scatter gather entries (16 - 128)"
-	depends on FUSION
 	default "128"
 	range 16 128
 	help
@@ -101,4 +102,4 @@ config FUSION_LAN
 
 	  If unsure whether you really want or need this, say N.
 
-endmenu
+endif # FUSION

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Use menuconfig objects - Fusion
  2007-07-21 18:56 ` [PATCH] Use menuconfig objects - Fusion Jan Engelhardt
@ 2007-07-21 19:05   ` Robert P. J. Day
  2007-07-21 19:14     ` Jan Engelhardt
  0 siblings, 1 reply; 6+ messages in thread
From: Robert P. J. Day @ 2007-07-21 19:05 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Linux Kernel Mailing List

On Sat, 21 Jul 2007, Jan Engelhardt wrote:

> -menu "Fusion MPT device support"
> +menuconfig FUSION
> +	bool "Fusion MPT device support"
>  	depends on PCI
> +	---help---
> +	Say Y here to get to see options for Fusion Message
> +	Passing Technology (MPT) drivers.
> +	This option alone does not add any kernel code.
> +
> +	If you say N, all options in this submenu will be skipped and disabled.
>
...
> +if FUSION
>
>  config FUSION_SPI
...
> +endif # FUSION


  i just *know* i'm going to regret asking this, but is there a
compelling reason why the internal contents of a "menuconfig FUBAR"
needs to still be surrounded by a "if FUBAR" condition?  wouldn't it
be philosophically cleaner if the internals of a menuconfig structure
*automatically* depended on selection of the menuconfig and the "if"
part was implicit?

  and having said that, i realize that there are menuconfig examples
for which the above is not strictly true, but i can't remember where
i've seen them.  all i remember about them is that they we're a bit
confusing.

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Use menuconfig objects - Fusion
  2007-07-21 19:05   ` Robert P. J. Day
@ 2007-07-21 19:14     ` Jan Engelhardt
  2007-07-21 19:15       ` Robert P. J. Day
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Engelhardt @ 2007-07-21 19:14 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux Kernel Mailing List


On Jul 21 2007 15:05, Robert P. J. Day wrote:
>> +menuconfig FUSION
>...
>> +if FUSION
>>
>>  config FUSION_SPI
>...
>> +endif # FUSION
>
>  i just *know* i'm going to regret asking this, but is there a
>compelling reason why the internal contents of a "menuconfig FUBAR"
>needs to still be surrounded by a "if FUBAR" condition?

Note that if/endif actually translates to a "depends on" for every
contained object. I prefer the reduced clutter [if/endif] over having
explicit depends on on every object, since it is redundant.

>wouldn't it
>be philosophically cleaner if the internals of a menuconfig structure
>*automatically* depended on selection of the menuconfig and the "if"
>part was implicit?

"menuconfig" is not a start marker like "menu" was. Hence it has no "stop"
marker either. We would need a new object type for that.

>  and having said that, i realize that there are menuconfig examples
>for which the above is not strictly true, but i can't remember where
>i've seen them.  all i remember about them is that they we're a bit
>confusing.


	Jan
-- 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Use menuconfig objects - Fusion
  2007-07-21 19:14     ` Jan Engelhardt
@ 2007-07-21 19:15       ` Robert P. J. Day
  2007-07-21 19:35         ` Jan Engelhardt
  0 siblings, 1 reply; 6+ messages in thread
From: Robert P. J. Day @ 2007-07-21 19:15 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Linux Kernel Mailing List

On Sat, 21 Jul 2007, Jan Engelhardt wrote:

>
> On Jul 21 2007 15:05, Robert P. J. Day wrote:
> >> +menuconfig FUSION
> >...
> >> +if FUSION
> >>
> >>  config FUSION_SPI
> >...
> >> +endif # FUSION
> >
> >  i just *know* i'm going to regret asking this, but is there a
> >compelling reason why the internal contents of a "menuconfig FUBAR"
> >needs to still be surrounded by a "if FUBAR" condition?
>
> Note that if/endif actually translates to a "depends on" for every
> contained object. I prefer the reduced clutter [if/endif] over
> having explicit depends on on every object, since it is redundant.

oh, i absolutely agree with you there.

> >wouldn't it be philosophically cleaner if the internals of a
> >menuconfig structure *automatically* depended on selection of the
> >menuconfig and the "if" part was implicit?
>
> "menuconfig" is not a start marker like "menu" was. Hence it has no
> "stop" marker either. We would need a new object type for that.

http://www.linuxrocket.net/index.cgi?a=MailArchiver&ma=ShowMail&Id=525787

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Use menuconfig objects - Fusion
  2007-07-21 19:15       ` Robert P. J. Day
@ 2007-07-21 19:35         ` Jan Engelhardt
  2007-07-21 19:36           ` Robert P. J. Day
  0 siblings, 1 reply; 6+ messages in thread
From: Jan Engelhardt @ 2007-07-21 19:35 UTC (permalink / raw)
  To: Robert P. J. Day; +Cc: Linux Kernel Mailing List


On Jul 21 2007 15:15, Robert P. J. Day wrote:
>> >wouldn't it be philosophically cleaner if the internals of a
>> >menuconfig structure *automatically* depended on selection of the
>> >menuconfig and the "if" part was implicit?
>>
>> "menuconfig" is not a start marker like "menu" was. Hence it has no
>> "stop" marker either. We would need a new object type for that.
>
>http://www.linuxrocket.net/index.cgi?a=MailArchiver&ma=ShowMail&Id=525787

Exactly like that. But kconfig don't have selectablemenu (yet).


	Jan
-- 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] Use menuconfig objects - Fusion
  2007-07-21 19:35         ` Jan Engelhardt
@ 2007-07-21 19:36           ` Robert P. J. Day
  0 siblings, 0 replies; 6+ messages in thread
From: Robert P. J. Day @ 2007-07-21 19:36 UTC (permalink / raw)
  To: Jan Engelhardt; +Cc: Linux Kernel Mailing List

On Sat, 21 Jul 2007, Jan Engelhardt wrote:

>
> On Jul 21 2007 15:15, Robert P. J. Day wrote:
> >> >wouldn't it be philosophically cleaner if the internals of a
> >> >menuconfig structure *automatically* depended on selection of the
> >> >menuconfig and the "if" part was implicit?
> >>
> >> "menuconfig" is not a start marker like "menu" was. Hence it has no
> >> "stop" marker either. We would need a new object type for that.
> >
> >http://www.linuxrocket.net/index.cgi?a=MailArchiver&ma=ShowMail&Id=525787
>
> Exactly like that. But kconfig don't have selectablemenu (yet).

well, fine ... i'll see what i can do.  :-)

rday
-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2007-07-21 19:38 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <200705102317.l4ANHrUC001117@shell0.pdx.osdl.net>
2007-07-21 18:56 ` [PATCH] Use menuconfig objects - Fusion Jan Engelhardt
2007-07-21 19:05   ` Robert P. J. Day
2007-07-21 19:14     ` Jan Engelhardt
2007-07-21 19:15       ` Robert P. J. Day
2007-07-21 19:35         ` Jan Engelhardt
2007-07-21 19:36           ` Robert P. J. Day

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®