On Wed, May 26, 2021 at 09:37:37AM +0200, Jan Beulich wrote:
> We shouldn't default to include any unsupported code in the shim. Mark
> the setting as off, replacing the ARGO specification. This points out
> anomalies with the scheduler configuration: Unsupported schedulers
> better don't default to Y in release builds (like is already the case
> for ARINC653). Without at least the SCHED_NULL adjustments, the shim
> would suddenly build with RTDS as its default scheduler.
>
> As a result, the SCHED_NULL setting can also be dropped from defconfig.
>
> Clearly with the shim defaulting to it, SCHED_NULL must be supported at
> least there.
>
> Signed-off-by: Jan Beulich <jbeul...@suse.com>
> Acked-by: Roger Pau Monné <roger....@citrix.com>
> ---
> v2: Also drop SCHED_NULL setting from defconfig. Make SCHED_NULL the
> default when PV_SHIM_EXCLUSIVE.
> ---
> I'm certainly open to consider alterations on the sched/Kconfig
> adjustments, but _something_ needs to be done there. In particular I
> was puzzled to find the NULL scheduler marked unsupported. Clearly with
> the shim defaulting to it, it must be supported at least there.
>
> In a PV_SHIM (but perhaps !PV_SHIM_EXCLUSIVE) build with the build-time
> default not being SCHED_NULL, when actually running as shim I can't seem
> to see how the null scheduler would get chosen as the default
> nevertheless. Shouldn't this happen (in the absence of a command line
> override)?
I wondered the same yesterday and got to the conclusion that it's
then the duty of the user to add pvshim_extra="sched=null" to the
config file.
I think it would indeed be useful to select the null scheduler at
runtime if booting in shim mode and null is present, but then we would
be ignoring the default scheduler selection made in Kconfig, which
could be confusing.
It's also confusing that the scheduler that gets set as the default
when shim exclusive is selected is not available to enable/disable:
[*] Credit scheduler support (NEW)
[*] Credit2 scheduler support (NEW)
Default Scheduler? (Null Scheduler) --->
Thanks, Roger.
