From: Demi Marie Obenour <demiobenour@gmail.com>
To: Julian Braha <julianbraha@gmail.com>, nathan@kernel.org, nsc@kernel.org
Cc: jani.nikula@linux.intel.com, akpm@linux-foundation.org,
gary@garyguo.net, ljs@kernel.org, arnd@arndb.de,
gregkh@linuxfoundation.org, masahiroy@kernel.org,
ojeda@kernel.org, corbet@lwn.net, qingfang.deng@linux.dev,
linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-doc@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [RFC v2 0/2] add kconfirm
Date: Mon, 11 May 2026 00:24:28 -0400 [thread overview]
Message-ID: <8fe7c7c8-00f7-4a72-a984-e929f71bec22@gmail.com> (raw)
In-Reply-To: <20260509203808.1142311-1-julianbraha@gmail.com>
[-- Attachment #1.1.1: Type: text/plain, Size: 6508 bytes --]
On 5/9/26 16:38, 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
>
> 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@linux-foundation.org/
> 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@gmail.com/
>
> False Alarms:
> kconfirm aims for zero false-positives, which is currently true for the
> default checks (as far as I'm aware - but there are hundreds to go
> through); this is not really possible for dead link checks, as this
> depends on an internet connection, and we do not attempt to bypass bot
> blocks. For this reason, dead link checking is disabled by default, but
> I've provided an example below of how to enable it. Additionally, you can
> view my previous message to the mailing list with hand-verified dead links
> here:
> https://lore.kernel.org/all/6732bf08-41ee-40c4-83b2-4ae8bc0da7cf@gmail.com/
>
> Additionally, there is an optional check to detect config options that
> select visible config options, as requested by Jani during the review of
> the first version of this RFC:
> https://lore.kernel.org/all/dcb7439832f0bb35598fba653d922b5f6a4d0058@intel.com/
>
> Even after deduplicating across architectures, there are well over 1,000
> instances of these select-visible cases, and I suspect that, despite the
> Kconfig documentation saying select-visible should be avoided, some
> exceptions will be made. So, I have left this check disabled by default,
> keeping in line with the goal of having a low-noise checker. If interested
> in using it, I have included an example below of how to enable this check.
>
> Current State of Alarms:
> On Linux v7.1-rc2 (which this RFC is based), there are 489 alarms coming
> from the default set of checks, and an additional 1,789 alarms if enabling
> the optional select-visible check. These counts are with deduplication
> across architectures, a change that was made to the tool's CLI from RFC v1
> to RFC v2. The last time I checked linux-next (next-20260427), there were
> 81 unique dead links.
>
> The most critical check is the dead default statements, which has surfaced
> a few misconfiguration bugs (fortunately, just for kunit tests), see
> examples:
> https://lore.kernel.org/all/20260323124118.1414913-1-julianbraha@gmail.com/
> and:
> https://lore.kernel.org/all/20260323123536.1413732-1-julianbraha@gmail.com/
>
> But hopefully kconfirm can ease maintenance and we can prevent more of
> these from making it into the tree in the future.
>
> Use it:
> You can test out kconfirm with this patch series by compiling and running
> kconfirm like this:
>
> `make kconfirm`
>
> To enable the select-visible check:
> `KCONFIRM_ARGS="--enable select_visible" make kconfirm`
>
> And to enable dead link checks in the help texts:
> `KCONFIRM_ARGS="--enable dead_links" make kconfirm`
>
> Note that it is not architecture-specific; it runs tree-wide. Any alarms
> that are specific to one or more architectures will have a tag using the
> config option(s) of the architecture(s), for example: [X86] or [X86, ARM]
>
> The dependencies are vendored in scripts/kconfirm/vendor so that no
> internet connection is needed to compile the code. The total size of the
> tool with dependencies is 49mb, making it a large amount of code, though
> still in the ballpark of perf, at 42mb.
>
> I managed to reduce the size of the vendored dependencies from 264mb by
> taking multiple approaches:
> 1. Removed 'rustls' for TLS and instead use the user's system OpenSSL
> 2. Replaced the 'reqwest' crate with the smaller 'ureq' crate
> 3. Disabled the default features of the dependencies, and only enabled
> whatever is needed by kconfirm
> 3. Filtered out various things from the vendored dependencies unneeded for
> compilation (e.g. docs & tests for dependencies)
> 4. Filtered out platform-specific code that isn't needed for linux
> developers (e.g. Nintendo 3DS)
>
> The script I ran to generate the vendored dependencies with filtering is
> available in scripts/kconfirm/vendor_dependencies.sh
>
> Requested feedback:
> 1. I would like to know if anyone thinks that the select-visible check
> should be enabled by default.
> 2. The only "person" that commented on `make clean` deleting the compiled
> kconfirm binary/artifacts was sashiko-bot. Now, there is just
> `make kconfirmclean` for deleting 'scripts/kconfirm/release/', and
> `make clean` no longer touches kconfirm. Please let me know if anyone has
> requested changes on the integration with Make.
>
> Thanks,
> Julian Braha
> ---
> Changes since v1:
> - vendored dependencies instead of requiring an internet connection
> - removed Cargo.lock
> - replaced reqwest dependency with smaller ureq
> - removed rustls, expect user to have openssl instead
> - added select-visible check based on Jani's feature request
> - added invalid (reverse) range check
> - deduplicating alarms that appear for multiple architectures
> - `make clean` no longer deletes kconfirm's build artifacts
> - typo fixes in documentation
> - added patch description for the main "add kconfirm" patch (patch 1/2)
>
> Link to v1:
> https://lore.kernel.org/all/20260427174429.779474-1-julianbraha@gmail.com/
> ---
This adds too many dependencies.
Some suggestions:
- Use system libcurl instead of ureq.
- Use libc getopt_long instead of clap.
- Use manual FFI bindings instead of third-party crates.
- Use the C Kconfig parser instead of a third-party library.
Ideally, this shouldn't need any dependencies from crates.io
at all.
--
Sincerely,
Demi Marie Obenour (she/her/hers)
[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 7253 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2026-05-11 4:24 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-09 20:38 [RFC v2 0/2] add kconfirm Julian Braha
2026-05-09 20:38 ` [RFC PATCH v2 1/2] scripts: " Julian Braha
2026-05-11 9:57 ` Jani Nikula
2026-05-11 13:18 ` Julian Braha
2026-05-09 20:38 ` [RFC PATCH v2 2/2] Documentation: dev-tools: " Julian Braha
2026-05-10 5:06 ` [RFC v2 0/2] " Jan Engelhardt
2026-05-10 9:49 ` Miguel Ojeda
2026-05-10 23:06 ` Julian Braha
2026-05-13 14:12 ` Julian Braha
2026-05-10 23:28 ` Jan Engelhardt
2026-05-13 15:52 ` Miguel Ojeda
2026-05-11 4:24 ` Demi Marie Obenour [this message]
2026-05-13 13:59 ` Julian Braha
2026-05-13 15:22 ` Nicolas Schier
2026-05-13 16:04 ` Julian Braha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8fe7c7c8-00f7-4a72-a984-e929f71bec22@gmail.com \
--to=demiobenour@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=corbet@lwn.net \
--cc=gary@garyguo.net \
--cc=gregkh@linuxfoundation.org \
--cc=jani.nikula@linux.intel.com \
--cc=julianbraha@gmail.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=masahiroy@kernel.org \
--cc=nathan@kernel.org \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=qingfang.deng@linux.dev \
--cc=rust-for-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.