On 7/1/22 1:48 AM, Miroslav Benes wrote:
Hi Shuah,
On Thu, 30 Jun 2022, Shuah Khan wrote:
Sorry Nack on this. Let's not add modules under selftests. Any usage of module_init() doesn't belong under selftests.
as mentioned before, that ship has already sailed with tools/testing/selftests/bpf/bpf_testmod/bpf_testmod.c. Anyway...
Just because of one module under bpf doesn't mean that now we can add more. bpf test is some ways is not a good example or model to use. bpf test requires specific environment and its needs are different from other tests.
You wrote before that you did not have a problem with it. And you would not have a problem with Marcos' approach if modules can be compiled and if not, the tests would fail gracefully. What has changed? If you see a problem in the patch set regarding this, can we fix it?
Yes I did and after reviewing and thinking about it some more, I decided this is the right direction go down on.
Leave these under lib and use KSTM_MODULE_LOADERS to load these modules that live under lib.
I may misunderstand but KSTM_MODULE_LOADERS does not seem to provide the flexibility we need (yes, it could be hacked around, but I do not think that the result would be nice). See what we have in tools/testing/selftests/livepatch/functions.sh to make sure that a live patch module is properly loaded and unloaded.
My main question is different though. As Marcos mentioned before, we would like to have our tests really flexible and a possibility to prepare and load different live patch modules based on a template is a part of it. What is your proposal regarding this? I can imagine having a template in lib/livepatch/ which would not be compilable and a script in tools/testing/selftests/livepatch/ would copy it many times, amend the copies (meaning parameters would be filled in with sed or the code would be changed), compile them and load them. But this sounds horrible to me, especially when compared to Marcos' approach in this patch set which is quite straightforward.
I have to think about this some more to get a better feel for the use-case.
Then there is an opportunity which Joe described. To run the latest livepatch kselftests on an older kernel. Having test modules in lib/ is kind of an obstacle there.
You can revision match if you think you have to have kernel and livepatch test be the same version.
thanks, -- Shuah