linux-kernel - Re: kconfig - scan all Kconfig files

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.0705210235030.1817@scrub.home>
Date:	Mon, 21 May 2007 03:43:45 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	Sam Ravnborg <sam@...nborg.org>
cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: kconfig - scan all Kconfig files

Hi,

On Sun, 20 May 2007, Sam Ravnborg wrote:

> I did a quick hack so kconfig could scan all Kconfig files
> in the kernel tree.
> By scanning all Kconfig files we gain the following:
> 
> -> kconfig can report when a depends on refer to an undefined symbol
> -> kconfig can report when a select refer to an undefined symbol
> 
> Later we can push a lot of common stuff to the top-level Kconfig file.
> And that may in the end result in a better structure overall for
> Kconfig files.

Well, some of that stuff should already happen earlier (and included from 
the arch Kconfig files), but that doesn't work for everything.
I don't think that simply allowing to parse a file multiple times is the 
right answer, as it duplicates a lot of data. A simple example would be 
help texts, right now they are per symbol, but they should really be per 
menu, so archs can provide different help texts for something.
"source" should become a bit more intelligent and parse a file only once 
and link the data into the menu structure.

> All the "choice values currently only support a single prompt" are caused
> by using the same config symbol in a choice list for several architectures.
> That will be the biggest challenge to fix before we can introduce this patch.
> Maybe we can extend kconfig to accept it???

Define "accept".
The basic rule for choice values must not be violated - none of them may 
depend on another value in the same group. The dependency tree allows for 
no loops, these choice groups allow for the only exception, but it has to 
stay within that group.
One option I'm thinking about is to extend that group by naming the choice 
option, so kconfig knows they are related. This won't work for everything, 
so quite some renaming may be needed.

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/