Re: [for-4.17] automation: Do not use null scheduler for boot cpupools test

[Jan Beulich <jbeulich@xxxxxxxx>]

On 21.10.2022 19:21, Andrew Cooper wrote:
> On 21/10/2022 17:53, Michal Orzel wrote:
>> Null scheduler is not enabled on non-debug Xen builds so the current
>> test can lead to a failure on such jobs. We still want to test that we
>> can assign the cpupool to a domU with a different scheduler than default
>> one (credit2). Switch to credit as it is enabled by default.
>>
>> Fixes: 36e3f4158778 ("automation: Add a new job for testing boot time 
>> cpupools on arm64")
>> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
> 
> /sigh - I'm sure I nacked that stupidity to begin with.  apparently not...
> 
> It is totally bogus for CONFIG_DEBUG to influence logical chunks of
> functionality like this.  The CI script is good in its current form.

Assuming you mean defaults of settings, I'm afraid I see nothing bogus
there at all. What's wrong with enabling more functionality by default
in debug builds, for people to easily use/test them? Yet keeping
unsupported stuff off by default in release builds? That said, ...

> RTDS and ARINC should be default n.
> 
> NULL is more tricky.  PV_SHIM is explicitly security supported, and has
> been for years, so the "UNSUPPORTED" is bogus, whatever the default is.
> 
> As NULL is explicitly tested in CI, it's clearly supported, and probably
> ought to be on default.

... the state of the NULL scheduler wrt its use by the shim has been
puzzling me before.

> Please instead fix Kconfig to not be broken.  That will be a far better
> fix overall for people.
> 
> As a more general note, tests which are using non-default pieces of
> logic ought to activate them explicitly.

Imo _this_ is the immediate course of action to take. What the appropriate
settings are in Kconfig may be less straightforward to determine (see also
Stefano's and Julien's replies).

Jan