On 24/10/2022 07:29, Jan Beulich wrote:
> 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.or...@amd.com>
>> /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.
It's a complete violation of any reasonable interpretation of DEBUG.
Apart from creating the bug at the centre of this thread, one does not
turn on DEBUG to get at this functionality in the first place, so the
options should not be interlinked.
>> 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.
NULL is exactly what the shim wants, and it gets thorough testing.
The only remaining problem is the paperwork. NULL is already "security
supported in pv shim", hence the unsupported tag is bogus.
~Andrew
