2023-11-28 00:47:04 +00:00
option('bpf_clang', type: 'string', value: 'clang',
description: 'clang to use when compiling .bpf.c')
2024-03-08 19:32:47 +00:00
option('bpftool', type: 'string',
description: 'bpftool to use when generating .bpf.skel.h. By default, bpftool is automatically downloaded and built during setup. To use an existing bpftool binary, point this to the bpftool path or set it to "disabled" to have meson try to find it automatically')
2023-11-28 00:47:04 +00:00
option('libbpf_a', type: 'string',
2024-02-29 21:42:13 +00:00
description: 'By default, libbpf is automatically downloaded and built during setup. To use an existing static library, point this to the libbpf.a file or set it to "disabled" to use dynamic linking')
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'
)
