Message-ID: <20110216044830.GA19364@ulf>
Date:	Wed, 16 Feb 2011 05:48:32 +0100
From:	Ulf Magnusson <ulfalizer.lkml@...il.com>
To:	Michal Marek <mmarek@...e.cz>
Cc:	linux-kbuild@...r.kernel.org, rdunlap@...otime.net,
	akpm@...ux-foundation.org, andrea.gelmini@...ma.net,
	linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	Arnaud Lacombe <lacombar@...il.com>
Subject: Re: [PATCH] [ANNOUNCE] kconfig: Kconfiglib: a flexible Python
 Kconfig parser

On Fri, Feb 11, 2011 at 12:14:36AM +0100, Michal Marek wrote:
> On 2.2.2011 00:27, Ulf Magnusson wrote:
> > Hi,
> > 
> > This is the initial release of Kconfiglib: a Python library for
> > scripting, debugging, and extracting information from Kconfig-based
> > configuration systems.  It can be used to programmatically generate a
> > .config when the '*conf' tools are too inflexible, to quickly find out
> > interesting information about a Kconfig configuration such as dependency
> > relations between symbols and where undefined symbols are referenced,
> > and in applications that need to parse and extract information from
> > Kconfig files.
> > 
> > For a much longer introduction including multiple examples, see
> > arch/kconfig/kconfiglib.py.
> 
> Hi,
> 
> this looks like a very powerful tool, but I have a similar concern like
> Arnaud had - being completely standalone, it reimplements most of the C
> kconfig code. One option to reduce this duplication would be a swig
> wrapper, another one would be to let the C code parse the Kconfig files
> and write the required information in some digested form, that would be
> easier to parse by scripts. Something like:
> $ scripts/kconfig/conf_inspect --kconfig=Kconfig --eval='FOO || BAR'
> y
> $ scripts/kconfig/conf_inspect ... --dump-symbols
> config FOO
> type: bool
> valule: m
> visible: y
> prompt: "zzz"
> depends: X & Y
> select: Z
> ...
> $ scripts/kconfig/conf_inspect ... --dump-symbols \
>     --fields='depends,select,value'
> config FOO
> depends: X & Y
> select: Z
> value: m
> 
> config BAR
> ...
> 
> etc. The idea is that for instance instead of parsing the Kconfig files,
> the Python code could fill it's data structures by reading the flat dump
> provided by the C kconfig. There would be still lot to do in Python,
> e.g. parsing and evaluating expressions, but it would be a small step
> forward already. And people wanting to write quick&dirty scripts in
> bash/awk/perl would make use of the C code as well.
>
Offloading some of the parsing to a new tool would probably be doable,
though some Kconfig subleties might complicate things. For example,
symbols that appear within choices aren't seen as real selectable choice
items if they depend on previous symbols in specific ways (see
_determine_actual_items() in kconfiglib.py), and capturing this
information in the output while at the same preserving the ordering of
the symbols could be messy. I guess you could sort this out within
Kconfiglib instead, though other tools might then have to reimplement
the same (messy) rules.

I'm not so sure about offloading anything else this way. For dynamically
updating symbol values in a script you would need to somehow preserve
state between invocations (or pass huge lists of assignments back and
forth), which could lead to an unwieldy protocol. You might need to go
the SWIG route instead.

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

Powered by blists - more mailing lists