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