Kconfig: defaults for UNSUPPORTED

Kconfig: defaults for UNSUPPORTED

[Jan Beulich]

Hello,

when commit d96e5e6c1214 added UNSUPPORTED, it left x86'es TBOOT
default untouched. This means we default-enable an unsupported
setting, which doesn't look to be what's generally wanted. I can
see defaulting to DEBUG as reasonable, and SCHED_NULL's defaulting
to enabled when PV_SHIM can imo also be justified (there it's
rather that UNSUPPORTED is inapplicable for the shim case, and the
adjustment was also done subsequent to the named commit).

Shouldn't we therefore have a rule of thumb that UNSUPPORTED
entries only ever have no "default" (implying "n") or default to
no more than DEBUG?

Thanks for opinions,
Jan

Re: Kconfig: defaults for UNSUPPORTED

[Bertrand Marquis]

Hi,

> On 1 Mar 2022, at 08:24, Jan Beulich <jbeulich@suse.com> wrote:
> 
> Hello,
> 
> when commit d96e5e6c1214 added UNSUPPORTED, it left x86'es TBOOT
> default untouched. This means we default-enable an unsupported
> setting, which doesn't look to be what's generally wanted. I can
> see defaulting to DEBUG as reasonable, and SCHED_NULL's defaulting
> to enabled when PV_SHIM can imo also be justified (there it's
> rather that UNSUPPORTED is inapplicable for the shim case, and the
> adjustment was also done subsequent to the named commit).
> 
> Shouldn't we therefore have a rule of thumb that UNSUPPORTED
> entries only ever have no "default" (implying "n") or default to
> no more than DEBUG?

In general that would definitely make sense yes even though there might be
exceptions due to for example a dependency to an other unsupported parameter.

I would definitely agree with this.

Cheers
Bertrand

> 
> Thanks for opinions,
> Jan
> 
>