Re: [PATCH v1 01/10] kconfig-checker: Add schema for rule files

["Ahmed S. Darwish" <darwi@linutronix.de>]

Hi Julian,

Thanks for all the feedback!

On Sun, 08 Nov 2026, Julian Braha wrote:
>
> On 11/6/26 09:19, Ahmed S. Darwish wrote:
> >
> > --- /dev/null
> > +++ b/tools/kconfig-checker/schema.yml
...
> > +
> > +        #
> > +        # Expected value for the matching kernel configuration option.
> > +        #
> > +        # Values:
> > +        #
> > +        #   y        option is expected to be enabled (built-in or module).
>
> Kconfig's tristates use 3-state logic. It seems like you're
> approximating 'm' as 'y'?
>

You're correct.

'y' is deceiving, even with the comment beside it saying that it implies
either a built-in or a module.

I guess it would be better to have the expected values like:

   expected:
      type: string
      enum: [enabled, disabled, allowed]

As a bonus, 'enabled' and 'disabled' rhymes well with 'allowed'.

So the policies can be:

  - name: CONFIG_PREEMPT_RT
    expected: enabled
    ...

  - name: CONFIG_NO_HZ_FULL
    expected: disabled
    ...

  - name: CONFIG_DEBUG_FS
    expected: allowed
    ...

I think that's much cleaner.

> These are meaningfully different values :/

I wrote some policies beside the PREEMPT_RT one, and the main requirement
was always that a certain kernel feature is either enabled or disabled.

In the future, I can add;

    expected:
      type: string
      enum: [enabled, disabled, allowed, builtin-only, module]

But so far, there was no need for that.

> > +        #   n        option is expected to be disabled or unset.
> > +        #   allowed  option is permitted and must not be reported as a violation.
> > +        #            This is used to exempt a specific symbol from a broader
> > +        #            `name_pattern` rule  with `expected: n`.
> > +        #
> > +        expected:
> > +          type: string
> > +          enum: [y, n, allowed]
>
> What if a user wants to specify that the value can be 'n' or 'y', but
> not 'm'?

Is this a real-world use case?

I did not encounter a need for making the expected values that complex
before.

Thanks!

--
Ahmed S. Darwish
Linutronix GmbH