2023-11-28 00:47:04 +00:00
|
|
|
option('bpf_clang', type: 'string', value: 'clang',
|
|
|
|
|
description: 'clang to use when compiling .bpf.c')
|
|
|
|
|
option('bpftool', type: 'string', value: 'bpftool',
|
|
|
|
|
description: 'bpftool to use when generating .bpf.skel.h')
|
|
|
|
|
option('libbpf_a', type: 'string',
|
2024-02-29 17:39:01 +00:00
|
|
|
description: 'Static libbpf.a to use')
|
2023-11-28 00:47:04 +00:00
|
|
|
option('libbpf_h', type: 'array',
|
2023-12-02 00:49:32 +00:00
|
|
|
description: 'libbpf header directories, only meaningful with libbpf_a option')
|
2023-12-01 21:58:56 +00:00
|
|
|
option('cargo', type: 'string', value: 'cargo',
|
|
|
|
|
description: 'cargo to use when building rust sub-projects')
|
2023-12-08 18:39:06 +00:00
|
|
|
option('cargo_home', type: 'string',
|
|
|
|
|
description: 'CARGO_HOME env to use when invoking cargo')
|
|
|
|
|
option('offline', type: 'boolean', value: 'false',
|
|
|
|
|
description: 'Compilation step should not access the internet')
|
2023-12-09 13:20:44 +00:00
|
|
|
option('enable_rust', type: 'boolean', value: 'true',
|
|
|
|
|
description: 'Enable rust sub-projects')
|
ci: use virtme-ng to test the schedulers
Use virtme-ng to run the schedulers after they're built; virtme-ng
allows to pick an arbitrary sched-ext enabled kernel and run it
virtualizing the entire user-space root filesystem, so we can basically
exceute the recompiled schedulers inside such kernel.
This should allow to catch potential run-time issue in advance (both in
the kernel and the schedulers).
The sched-ext kernel is taken from the Ubuntu ppa (ppa:arighi/sched-ext)
at the moment, since it is the easiest / fastest way to get a
precompiled sched-ext kernel to run inside the Ubuntu 22.04 testing
environment.
The schedulers are tested using the new meson target "test_sched", the
specific actions are defined in meson-scripts/test_sched.
By default each test has a timeout of 30 sec, after the virtme-ng
completes the boot (that should be enough to initialize the scheduler
and run the scheduler for some seconds), while the total lifetime of the
virtme-ng guest is set to 60 sec, after this time the guest will be
killed (this allows to catch potential kernel crashes / hangs).
If a single scheduler fails the test, the entire "test_sched" action
will be interrupted and the overall test result will be considered a
failure.
At the moment scx_layered is excluded from the tests, because it
requires a special configuration (we should probably pre-generate a
default config in the workflow actions and change the scheduler to use
the default config if it's executed without any argument).
Moreover, scx_flatcg is also temporarily excluded from the tests,
because of these known issues:
- https://github.com/sched-ext/scx/issues/49
- https://github.com/sched-ext/sched_ext/pull/101
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2023-12-24 08:09:25 +00:00
|
|
|
option('kernel', type: 'string', value: 'vmlinuz',
|
|
|
|
|
description: 'kernel image used to test schedulers')
|
2024-01-15 22:41:59 +00:00
|
|
|
option(
|
|
|
|
|
'systemd',
|
|
|
|
|
type: 'feature',
|
|
|
|
|
value: 'auto',
|
|
|
|
|
description: 'sd-notify support via libsystemd and install systemd unit files'
|
|
|
|
|
)
|
