Re: [RFC v3 0/3] add kconfirm

[Julian Braha <julianbraha@gmail.com>]

On 5/17/26 07:14, Demi Marie Obenour wrote:
>> Hi all,
>>
>> kconfirm has shrunk a lot since v2!
> Thanks for dropping so many of the dependencies!
> 
> It might be able to shrink it further by using the existing C Kconfig
> parser.  This has the advantage that it ensures kconfirm and Kconfig
> will interpret the Kconfig files the same way.  I'm not sure if
> that would be too much of a change.  That's up to you.
Hi Demi,

I did look into the in-tree parser after your suggestion in v2. What I
discovered was that this parser performs too much evaluation of the
kconfig code during parsing, making it unsuitable for purposes of static
analysis:

The in-tree parser doesn't actually output a parse tree that we can
traverse and analyze, which is how kconfirm currently works. Instead,
semantic actions directly construct the symbol table *during parsing*,
with that symbol table being different from ours. I think(?) this makes
the overall process faster (which is great for real-world kernel
builds), but for static analysis purposes, we really need to preserve
as much of the underlying code as we can. For example, we don't even
preprocess variables, because this allows us to analyze more regardless
of the host and target. (Well, architecture is the one exception there
because we need to resolve imports/"source".)

I do want to point out that Yann, the author of kconfirm's parsing
library (nom-kconfig) is CC'd on these RFCs and has done an awesome job
of supporting the parser and kconfirm's usage of it.

He also helped reduce the number of indirect dependencies pulled in by
the parser following your feedback in RFC v2.

- Julian Braha