On Fri 2023-12-08 09:06:30, Miroslav Benes wrote:
My idea is to abandon this way completely, take the selftests and build and run them on the system right away.
Both should be doable, hopefully, if we wire it all correctly... and document it.
I can't think of why it shouldn't continue to work, even in a future where newer livepatching selftests support older kernels. (We would just have newer selftests sources backported to test older kernel sources.)
Are there any test cases which truly need to be build on-the-fly? Aside from testing different toolchain pieces?
https://github.com/SUSE/qa_test_klp is what we would like to migrate to selftests to have just one place for all tests.
There is basically just one live patch template and one supporting kernel module template which is livepatched. The final result is driven by a set of macros and function parameters. In some cases more modules are compiled as parts of a test in a loop.
However, I do not think there is anything which truly needs to be built on-the-fly in the end. Everything can be worked around. Templates may be abandoned and we would have a live patch and a module(s) per test. Some tests are probably not worth it and may be removed. So it is a question of convenience and maintainability. When we, for example, simplified API and klp_register_patch() was removed, only one place needed to be amended. Also, the current state in lib/livepatch/ could be simplified with the proposed infrastructure as some files could be merged together.
In the patchset reworking livepatch states, I solved this problem by including the same sources in another module source, like:
$> cat lib/livepatch/test_klp_speaker_livepatch2.c // SPDX-License-Identifier: GPL-2.0 // Copyright (C) 2023 SUSE
/* Same livepatch with the same features. */ #include "test_klp_speaker_livepatch.c"
=========
$> cat lib/livepatch/test_klp_speaker2.c // SPDX-License-Identifier: GPL-2.0 // Copyright (C) 2023 SUSE
/* Use versioned function name for livepatched functions */ #define _VER_NAME(name) name ## 2
/* Same module with the same features. */ #include "test_klp_speaker.c"
==========
And the behavior was changed by module parameters. The test lookes like:
$> cat tools/testing/selftests/livepatch/test-modules.sh [...] start_test "multiple target modules"
load_mod $MOD_TARGET read_module_param $MOD_TARGET welcome
load_lp $MOD_LIVEPATCH add_applause=1 read_module_param $MOD_TARGET welcome
load_mod $MOD_TARGET2 read_module_param $MOD_TARGET2 welcome
unload_mod $MOD_TARGET2 disable_lp $MOD_LIVEPATCH read_module_param $MOD_TARGET welcome
unload_lp $MOD_LIVEPATCH unload_mod $MOD_TARGET
===========
It is a kind of hack. But it would allow to build and package the test modules. It has several advantages:
+ Less modules are needed. The behavior is modified by the parameters.
+ The separate parameters are easier to parse in compare with embedding the behavior into the module name.
+ Build problems would be solved before the packages reach QA department
+ The package would have lightweight dependencies.
+ Running the tests would be faster.
Regarding disadvantages:
+ The source included in all the other variants would be more complex.
But the same would happen when building the modules during the tests. It would also require a more complicated template and an extra script generating the particular module sources.
I personally prefer the solution with "#include" because it has all the mentioned advantages. The "#include" is a hack but it is needed only when we need more modules with all the features.
Best Regards, Petr