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

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <45619547.5070301@s5r6.in-berlin.de>
Date:	Mon, 20 Nov 2006 12:45:11 +0100
From:	Stefan Richter <stefanr@...6.in-berlin.de>
To:	Patrick Caulfield <pcaulfie@...hat.com>,
	Adrian Bunk <bunk@...sta.de>
CC:	cluster-devel@...hat.com, linux-kernel@...r.kernel.org,
	David Teigland <teigland@...hat.com>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [PATCH 2.6.19-rc5-mm2] fs/dlm: fix recursive dependency in Kconfig

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