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')
meson: introduce serialize build option
With commit 5d20f89a ("scheds-rust: build rust schedulers in sequence"),
schedulers are now built serially one after the other to prevent meson
and cargo from forking NxN parallel tasks.
However, this change has made building a single scheduler much more
cumbersome, due to the chain of dependencies.
For example, building scx_rusty using the specific meson target would
still result in all schedulers being built, because they all depend on
each other.
To address this issue, introduce the new meson build option
`serialize=true|false` (default is false).
This option allows to disable the schedulers' build chain, restoring the
old behavior.
With this option enabled, it is now possible to build just a single
scheduler, parallelizing the cargo build properly, without triggering
the build of the others. Example:
$ meson setup build -Dbuildtype=release -Dserialize=false
$ meson compile -C build scx_rusty
Signed-off-by: Andrea Righi <andrea.righi@canonical.com>
2024-06-28 08:42:04 +01:00
option('serialize', type: 'boolean', value: 'true',
description: 'Serialize the build of all schedulers')
2024-05-17 15:33:15 +01:00
option('enable_stress', type: 'boolean', value: 'true',
description: 'Enable stress tests')
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-08-09 20:15:13 +01:00
option('veristat_scheduler', type: 'string', value: '',
description: 'veristat scheduler to test')
2024-04-04 09:38:10 +01:00
option('kernel_headers', type: 'string', value: '',
description: 'kernel headers to build the 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'
)
2024-04-03 18:38:28 +01:00
option(
'openrc',
type: 'feature',
value: 'auto',
description: 'openrc init.d service file'
)
2024-05-13 14:52:06 +01:00
option(
'libalpm',
type: 'feature',
value: 'auto',
description: 'install pacman hooks'
)
