Re: [PATCH v1 00/10] tools: Introduce a kernel configuration checker

[Ahmed S. Darwish]

Hi Julian,

On Sun, 08 Nov 2026, Julian Braha wrote:
>
> Cool tool :)
>

Thanks!

> >
> > If no ruleset is specified, the target prints the available rulesets:
> >
> >     $ make checkconfig
> >       Usage: make RULES=<profile> [OVERLAY=<overlay>] checkconfig
> >       Available RULES: preempt_rt
> >
> > The overlay mechanism allows distributions, CI systems, and Board Support
>
> On the topic of distributions, this seems *a lot* like Canonical's
> Annotations [1], albeit yours uses YAML and supports matching option
> names with regex.

The difference is not only in the implementation details. Please see below.

> As you say about PREEMPT_RT configuration not being
> "one-size-fits-all", similarly there are 100+ Ubuntu kernels that need
> to adhere to a configuration "policy".
>
> So this seems to be a real problem that others are having.
>

Kernel configuration is definitely getting trickier.  That's why I've
contributed the PREEMPT_RT kernel configuration guide earlier:

   https://docs.kernel.org/core-api/real-time/kernel-configuration.html

Regarding the Canonical tool, it's the first time I see it.  From that
announce e-mail, it seems that they're using it for generating a .config:

   Starting with 22.04 (Jammy Jellyfish), Ubuntu kernels are now using
   only annotations to /generate/ their corresponding .config.

   ...

   $ ./debian/scripts/misc/annotations --arch amd64 --flavour generic > .config

Yocto also provides a very light concept of .config generation:

   https://docs.yoctoproject.org/kernel-dev/common.html#creating-configuration-fragments

But this tool does not conern itself with generation.  That is, Canonical
can use this tool to validate that they've generated the right thing! ;-)

> > For example:
> >
> >     $ ./tools/kconfig-checker/check.py check	\
> >           -c path/to/.config			\
> >           -r preempt_rt				\
> >           -o path/to/overlay.yml
> >
> > or:
> >
> >     $ make RULES=preempt_rt OVERLAY=path/to/overlay.yml checkconfig
> >
>
> I think the name will cause confusion.
>
> We already have some "kconfig checkers" in-tree, like
> scripts/kconfig-sym-check.pl
>
> But actually, your tool is quite unrelated, because that one checks
> 'Kconfig' source files, while yours checks the user's '.config' file.
>
> This has already caused some confusion in the past, for example in this
> thread [2], someone misunderstood which one 'kconfig-sym-check'
> actually checks.
>

Haha, good point :)

> In addition to .config vs Kconfig, the name is similar to
> 'kconfig-sym-check', but is not as descriptive about *what kind* of
> checks it performs.

Maybe "kconfig-audit" would be a good name?

It makes it clear that it "audits" a .config against a certain policy.

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH