Re: [RFC v2 0/2] add kconfirm

[Nicolas Schier]

On Sat, May 09, 2026 at 09:38:06PM +0100, Julian Braha wrote:
> Hi all,
> 
> kconfirm is a tool to detect misusage of Kconfig. It detects dead code,
> constant conditions, and invalid (reverse) ranges. There are also optional
> checks to detect config options that select visible config options, and to
> check for dead links in the help texts.
> 
> The full patchset (with the vendored dependencies) is available in my
> linux fork, git branch 'kconfirm_rfc2', and is based on linux v7.1-rc2:
> https://github.com/julianbraha/linux/tree/kconfirm_rfc2

Thanks!  I like the idea of having a static analyser for kconfig!



I guess the github branch is expected to work out of the box, but on my arm64
system this fails with:

    kconfirm$ make -j8 kconfirm
    error: no matching package named `env_logger` found
    location searched: crates.io index
    required by package `kconfirm-lib v0.9.0 (/data/kbuild/kbuild-fixes/kconfirm/scripts/kconfirm/kconfirm-lib)`
    As a reminder, you're using offline mode (--offline) which can sometimes cause surprising resolution failures, if this error is too confusing you may wish to retry without the offline flag.
    make[2]: *** [Makefile:17: kconfirm] Error 101
    make[1]: *** [kconfirm/Makefile:2244: kconfirm] Error 2
    make: *** [Makefile:248: __sub-make] Error 2
    [exit code 2]

and if 'kconfirm' does not need a .config file, you want to add 'kconfirm' to
the list of 'no-dot-config-targets' in top-level Makefile.


FTR: the 'kconfirm' and 'kconfirmclean' targets need some love: both do not
really integrate in kbuild, yet: 'kconfirm' is not working with out-of-source
builds (O=...), 'kconfirmclean' should not be required if 'make clean' is
supported correctly, and 'make mrproper' removes the whole scripts/kconfirm
tree due to the change in 'scripts/Makefile'.  (Tested?)

> 
> The patches sent here with the RFC include everything other than the
> vendored dependencies, including the tool's code, the documentation, and
> the makefile changes.
> Following this discussion:
> https://lore.kernel.org/all/20260405122749.4990dcb538d457769a3276e0@xxxxxxxxxxxxxxxxxxxx/
> in which Andrew brought up the possibility of moving kconfirm in-tree,
> I've prepared this RFC to do so. See also kconfirm's introduction to the
> mailing list:
> https://lore.kernel.org/all/6ec4df6d-1445-48ca-8f54-1d1a83c4716d@xxxxxxxxx/

The large amount of changes has been mentioned often enough;  even if all the
vendored dependencies could be dropped, I am not convinced yet, that it is a
good idea to maintain kconfirm in-tree due to its project size.

IMO, we need at least someone who steps up for maintaining kconfirm and
registers in a dedicated MAINTAINERS entry.  (My own rust knowledge is not good
enough for appropriate review, I can only offer some initial testing and
frequent use when it is working/integrated.)

Kind regards,
Nicolas