On Fri 2022-06-10 09:06:16, Joe Lawrence wrote: > On 6/9/22 4:16 PM, Shuah Khan wrote: > > On 6/3/22 8:32 AM, Marcos Paulo de Souza wrote: > >> Hi there, > >> > >> The first patch moves the current livepatch tests to selftests, > >> allowing it > >> be better suited to contain more complex tests, like using userspace C > >> code > >> to use the livepatched kernel code. As a bonus it allows to use > >> "gen_tar" to export the livepatch selftests, rebuild the modules by > >> running make in selftests/livepatch directory and simplifies the process > >> of creating and debugging new selftests. > >> > > > > In general selftests don't include modules. We keep test modules under lib. > > One of the reasons is that modules have dependencies on the kernel and > > should > > be built when kernel is built. > > > > I don't fully buy the argument that moving modules under selftest would > > simplify > > the process. > > > > Hi Shuah, > > I see that there is tools/testing/selftests/bpf/bpf_testmod/ which > claims to be a "conceptually out-of-tree module". Would similarly > moving livepatch test modules under tools/ give us flexibility to write > them build for multiple kernel versions? Then one could theoretically > build and run the latest, greatest selftests against older kernels > (assuming the associate script/module/kernel supports the idea)? +1 Another motivation is that the new selftest also needs an executable binary. It would be nice to handle both modules and binaries the same way. Honestly, lib/* is a mess. It mixes real functionality and test modules. The relation between the modules and tools/testing/* is far from clear. IMHO, it would be more clean to have the related stuff together. Of course, we could not move all test modules from lib/* easily. Some of them might be used on its own or even as built-in tests. But preventing the move looks like a step in the wrong direction to me. Best Regards, Petr
