linux-kernel - Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error

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: <20070205161744.GA31740@elte.hu>
Date:	Mon, 5 Feb 2007 17:17:44 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	David Woodhouse <dwmw2@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Cc:	Russell King <rmk+lkml@....linux.org.uk>
Subject: Re: [patch] MTD: fix DOC2000/2001/2001PLUS build error


* Russell King <rmk+lkml@....linux.org.uk> wrote:

> On Mon, Feb 05, 2007 at 04:56:27PM +0100, Ingo Molnar wrote:
> > btw., this whole select problem is not limited to Aunt Tillie: in a 
> > couple of cases in the past few months when i saw some weird code in a 
> > driver and tried to enable it i had to search around for many minutes 
> > and enable random options to figure out its config dependencies until i 
> > had the driver truly enabled. (if there's some easy solution to this 
> > then i'm all ears - but i exclude the easiest solution of adding me to 
> > the 'aunt' category ;-) I think that by blaming Aunt Tillie you might be 
> > missing the real problem.
> 
> Adding a 'select' statement might solve that particular problem:
> 
>  "What config symbols do I need to turn on to enable FOO"
> 
> but it creates another problem which is at precisely the same level. 
> IOW:
> 
>  "What config symbols do I need to turn off to disable FOO"
> 
> Both require the use of grep to solve it.  Both are as bad as each 
> other.  'select' only moves the problem - it doesn't actually solve 
> anything.

yes, in the example above i only outlined that the problem is real and 
not limited to Aunt Tillie's.

> The real problem is that "band-aiding" the problem is all too easy, so 
> we just bung a select in.  We're actually storing up bigger problems 
> for the future, making the kernel configuration system more and more 
> complex, sometimes creating circular dependencies through 
> select/depends, basically turning it into something several orders of 
> magnitude worse than the original shell scripts.

circular dependencies are nicely detected, warned about and worked 
around by the Kconfig system. I fixed one such bug recently. I have to 
say the Kconfig code has improved very significantly during the past few 
years and i dont want any of what i'm writing to be understood as a 
criticism. It's more in the direction of: 'ok, things are pretty nice 
and the config tree works currently, now lets make it even cleaner'.

> The only real way I see the problem truely getting solved is if folk 
> start standing up against throwing "select" in so there's some 
> motivation to actually fix the underlying problem.

the solution is i think two-fold and goes along the lines i outlined in 
the previous mail:

 - make dependencies as tree-alike as possible

note that the MTD problem was caused by those drivers not being part of 
a clean tree.

But even with a 100% clean tree structure there's a legitimate desire to 
select modules several layers down from the current 'leaf' nodes of the 
config tree:

 - provide a tool mode (not a Kconfig language feature) to navigate the
   complete tree of features (including currently disabled ones) and
   enable the selection of components (by automatically selecting all
   dependent features).

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