linux-kernel - Re: [PATCH] kconfig: warn about complex selects

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: <Pine.LNX.4.64.0805060511220.30555@scrub.home>
Date:	Tue, 6 May 2008 05:43:32 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Vegard Nossum <vegard.nossum@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>, Adrian Bunk <bunk@...nel.org>,
	Sam Ravnborg <sam@...nborg.org>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kconfig: warn about complex selects

Hi,

On Sun, 4 May 2008, Vegard Nossum wrote:

> One other idea that might be feasible in terms of both correctness and
> usability: If a symbol foo does "select bar", maybe foo should simply inherit
> bar's dependencies? This allows foo to be visible in most cases (when the
> dependencies of foo and bar are both satisified), but won't brute-force-enable
> any symbols.

Well, select was introduced for exactly this purpose.

In general I don't think it's possible to warn about this without 
producing a lot a false positives. If that would discourage people from 
using select everywhere, it might be an option but I'm afraid it will only 
cause them to add even more selects just to shut up the warnings.

Here is an example patch from me just a few days ago that might qualify as 
complex select, but is quite valid:

http://marc.info/?l=linux-kernel&m=120960318111346&w=2

The problem is usually that an option which might be visible, is selected 
without all the necessary build dependencies. The question is now how do 
you want to identify options which are necessary?
In this example a simple dependency check would flag that NEW_LEDS isn't 
selected, but NEW_LEDS is a pure config dependency, i.e. it has no effect 
on the build process.

It's not an impossible problem, but it's not trivial either, so that I 
haven't spend any time on it and rather would like to spend the energy on 
fixing the problem properly instead of working around it. And the problem 
BTW isn't select itself, the problem is that all the Kconfig dependencies 
have grown and become more complex, so it's becoming increasingly more 
difficult to maintain and to use them - select was never meant to solve 
this problem...

bye, Roman
--
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/