On 12/6/23 10:05, Miroslav Benes wrote:

On Fri, 1 Dec 2023, Joe Lawrence wrote:

quoted

On Tue, Oct 31, 2023 at 06:10:52PM -0300, Marcos Paulo de Souza wrote:

quoted

The modules are being moved from lib/livepatch to
tools/testing/selftests/livepatch/test_modules.

This code moving will allow writing more complex tests, like for example an
userspace C code that will call a livepatched kernel function.

The modules are now built as out-of-tree
modules, but being part of the kernel source means they will be maintained.

Another advantage of the code moving is to be able to easily change,
debug and rebuild the tests by running make on the selftests/livepatch directory,
which is not currently possible since the modules on lib/livepatch are
build and installed using the "modules" target.

The current approach also keeps the ability to execute the tests manually by
executing the scripts inside selftests/livepatch directory, as it's currently
supported. If the modules are modified, they needed to be rebuilt before running
the scripts though.

The modules are built before running the selftests when using the
kselftest invocations:

	make kselftest TARGETS=livepatch
or
	make -C tools/testing/selftests/livepatch run_tests

Quick question:

- We have been building with CONFIG_LIVEPATCH_TEST=m to generate the
  test modules at kernel build time

- Our packaging filters out the selftest scripts and supporting modules
  from the general kernel RPM package into their subpackages

- Tests are run as part of CKI or other manual tests by installing the
  pre-built packages from the previous step


After this patch, we would need to add something like the following to
our kernel build, before packaging:

  $ make KDIR=$(pwd) -C tools/testing/selftests/livepatch/
         ^^^^

If this is the correct way to build the test modules for *this* tree and
/lib/modules/$(shell uname -r)/build... it might be useful to document
in the commit message as an alternative use case.

So if I understand it correctly, you would like to stick to pre-building 
the modules (not in-tree but now after the kernel is build using the 
proposed way), package them and then install everything on a system 
running the respective kernel. A valid use case in my opinion.

That would accurate.  If this use case can be supported, it wouldn't
require changes to our CKI / testing scripts, only the post-build
packaging bits.

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?

-- 
Joe