[PATCH 2.6.19-rc5-mm2] fs/dlm: fix recursive dependency in Kconfig

[PATCH 2.6.19-rc5-mm2] fs/dlm: fix recursive dependency in Kconfig

[Stefan Richter]

make xconfig says
"Warning! Found recursive dependency: INET IPV6 DLM (null) DLM_TCP INET"

Seems to be another example of how badly the "select" keyword is handled
by the .config make targets. Replace all occurences of "select" in dlm's
Kconfig by "depends on" and some additional help texts.

Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>
---
 fs/dlm/Kconfig |   20 ++++++++++++++++----
 1 files changed, 16 insertions(+), 4 deletions(-)

Index: linux-2.6.19-rc5-mm2/fs/dlm/Kconfig
===================================================================
--- linux-2.6.19-rc5-mm2.orig/fs/dlm/Kconfig	2006-11-18 13:25:31.000000000 +0100
+++ linux-2.6.19-rc5-mm2/fs/dlm/Kconfig	2006-11-18 16:40:21.000000000 +0100
@@ -1,14 +1,22 @@
 menu "Distributed Lock Manager"
 	depends on EXPERIMENTAL
 
+comment "DLM requires CONFIGFS_FS in section 'Pseudo filesystems'"
+	depends on CONFIGFS_FS=n
+
+comment "DLM requires at least one of INET and IP_SCTP in section 'Networking'"
+	depends on !(INET || IP_SCTP)
+
 config DLM
 	tristate "Distributed Lock Manager (DLM)"
-	depends on IPV6 || IPV6=n
-	select CONFIGFS_FS
+	depends on (IPV6 || IPV6=n) && (INET || IP_SCTP) && CONFIGFS_FS
 	help
 	A general purpose distributed lock manager for kernel or userspace
 	applications.
 
+	If you want to link DLM statically instead of as a module, configure
+	IPV6 as statically linked too or switch it off.
+
 choice
 	prompt "Select DLM communications protocol"
 	depends on DLM
@@ -18,13 +26,17 @@ choice
 	SCTP supports multi-homed operations whereas TCP doesn't.
 	However, SCTP seems to have stability problems at the moment.
 
+	Activate INET (TCP/IP networking) in the Networking section
+	to be able to use DLM over TCP.  Activate SCTP in the
+	Networking section to use DLM over SCTP.
+
 config DLM_TCP
 	bool "TCP/IP"
-	select INET
+	depends on INET
 
 config DLM_SCTP
 	bool "SCTP"
-	select IP_SCTP
+	depends on IP_SCTP
 
 endchoice
 

Re: [PATCH 2.6.19-rc5-mm2] fs/dlm: fix recursive dependency in Kconfig

[Patrick Caulfield]

Stefan Richter wrote:
> make xconfig says
> "Warning! Found recursive dependency: INET IPV6 DLM (null) DLM_TCP INET"
> 
> Seems to be another example of how badly the "select" keyword is handled
> by the .config make targets. Replace all occurences of "select" in dlm's
> Kconfig by "depends on" and some additional help texts.
> 

The problem I found when using DEPENDS rather than SELECT in that position is that if you don't already have LINET or SCTP selected
then neither of the transports appear and you can effectively select the DLM without any transports. and that won't compile.

I prefer the already posted solutions to this.


patrick

Re: [PATCH 2.6.19-rc5-mm2] fs/dlm: fix recursive dependency in Kconfig

[Stefan Richter]

Patrick Caulfield wrote:
> The problem I found when using DEPENDS rather than SELECT in that
> position is that if you don't already have LINET or SCTP selected
> then neither of the transports appear and you can effectively
> select the DLM without any transports. and that won't compile.

That's why I added "depend on ... (INET || IP_SCTP)" at config DLM
itself. This problem does not exist with my patch AFAICS.

> I prefer the already posted solutions to this.

OK, I admit I didn't bother to look up if there were already other
approaches. I see that Adrian for example suggested "depend on ... INET"
even further up at the whole DLM menu.

There is one thing though which I have a slightly different opinion on
than that expressed by Adrian's patch
(http://lkml.org/lkml/2006/11/14/174): A subsystem outside of networking
shouldn't take specially into account that IP_SCTP itself depends in
INET --- even though it seems rather unlikely that CONFIG_IP_SCTP would
ever become independent of CONFIG_INET. I also don't agree with what
Adrian said in http://lkml.org/lkml/2006/11/15/85: The problem is not
really that option A selects option B but is missing a copy of B's
dependencies among its own dependencies, but rather that the .config
generator missed that "select" implies "depends on". "select" ==
"depends on, and switches magically on, so that the user doesn't have to
jump around in menues". This implies that .config generators should
switch on all dependencies of B if A selects B. If a generator is to
simplistic to support this, it should simply treat "select" exactly like
"depends on" in order to guarantee a correct .config.

Anyway. Whatever you chose to do (or already have chosen to do) in
fs/dlm/Kconfig, keep in mind that the "select" keyword is presently only
poorly supported by the various .config generators and that it forces UI
considerations into the Kconfig files which should better not be
overloaded with UI issues. Or in other words: It is rather easy to write
correct and well-supported Kconfig files if you stick with "depend on",
but you get into trouble fast with generous usage of "select".
-- 
Stefan Richter
-=====-=-==- =-== =-=--
http://arcgraph.de/sr/

Re: [PATCH 2.6.19-rc5-mm2] fs/dlm: fix recursive dependency in Kconfig

[Adrian Bunk]

On Mon, Nov 20, 2006 at 12:45:11PM +0100, Stefan Richter wrote:
>...
> Anyway. Whatever you chose to do (or already have chosen to do) in
> fs/dlm/Kconfig, keep in mind that the "select" keyword is presently only
> poorly supported by the various .config generators and that it forces UI
> considerations into the Kconfig files which should better not be
> overloaded with UI issues. Or in other words: It is rather easy to write
> correct and well-supported Kconfig files if you stick with "depend on",
> but you get into trouble fast with generous usage of "select".

For variables like NET or INET it doesn't matter in practice whether you 
use "select" or "depends on". But for other variables it makes it really 
hard for users to enable an option if you use "depends on".

> Stefan Richter

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [PATCH 2.6.19-rc5-mm2] fs/dlm: fix recursive dependency in Kconfig

[Randy Dunlap]

On Mon, 20 Nov 2006 18:45:09 +0100 Adrian Bunk wrote:

> On Mon, Nov 20, 2006 at 12:45:11PM +0100, Stefan Richter wrote:
> >...
> > Anyway. Whatever you chose to do (or already have chosen to do) in
> > fs/dlm/Kconfig, keep in mind that the "select" keyword is presently only
> > poorly supported by the various .config generators and that it forces UI
> > considerations into the Kconfig files which should better not be
> > overloaded with UI issues. Or in other words: It is rather easy to write
> > correct and well-supported Kconfig files if you stick with "depend on",
> > but you get into trouble fast with generous usage of "select".
> 
> For variables like NET or INET it doesn't matter in practice whether you 
> use "select" or "depends on". But for other variables it makes it really 
> hard for users to enable an option if you use "depends on".

Doing a "select" NET or INET enables a ton of code, which IMO
should be done explicitly, not covertly by a select.

---
~Randy

Re: [PATCH 2.6.19-rc5-mm2] fs/dlm: fix recursive dependency in Kconfig

[Adrian Bunk]

On Mon, Nov 20, 2006 at 03:35:28PM -0800, Randy Dunlap wrote:
> On Mon, 20 Nov 2006 18:45:09 +0100 Adrian Bunk wrote:
> 
> > On Mon, Nov 20, 2006 at 12:45:11PM +0100, Stefan Richter wrote:
> > >...
> > > Anyway. Whatever you chose to do (or already have chosen to do) in
> > > fs/dlm/Kconfig, keep in mind that the "select" keyword is presently only
> > > poorly supported by the various .config generators and that it forces UI
> > > considerations into the Kconfig files which should better not be
> > > overloaded with UI issues. Or in other words: It is rather easy to write
> > > correct and well-supported Kconfig files if you stick with "depend on",
> > > but you get into trouble fast with generous usage of "select".
> > 
> > For variables like NET or INET it doesn't matter in practice whether you 
> > use "select" or "depends on". But for other variables it makes it really 
> > hard for users to enable an option if you use "depends on".
> 
> Doing a "select" NET or INET enables a ton of code, which IMO
> should be done explicitly, not covertly by a select.

It seems you misunderstood my statement.

Let me try to phrase it differently:

A "depends on INET" is no problem for users since virtually everyone has 
INET enabled.

But a "depends on IP_SCTP" or a "depends on I2C_ALGOBIT" is a 
dependency that might create serious problems for users.

> ~Randy

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed