Him > > We store test modules in tools/testing/selftests/livepatch/test_modules/ > > now. Could you move klp_test_module.c there, please? You might also reuse > > existing ones for the purpose perhaps. > > IIUC, tools/testing/selftests/livepatch/test_modules/ is more like an out > of tree module. In the case of testing klp-build, we prefer to have it to > work the same as in-tree modules. This is important because klp-build > is a toolchain, and any changes of in-tree Makefiles may cause issues > with klp-build. Current version can catch these issues easily. If we build > the test module as an OOT module, we may miss some of these issues. > In the longer term, we should consider adding klp-build support to build > livepatch for OOT modules. But for now, good test coverage for in-tree > modules are more important.
Ok. I thought it would not matter but it is a fair point. > > What about vmlinux? I understand that it provides a lot more flexibility > > to have separate functions for testing but would it be somehow sufficient > > to use the existing (real) kernel functions? Like cmdline_proc_show() and > > such which we use everywhere else? Or would it be to limited? I am fine if > > you find it necessary in the end. I just think that reusing as much as > > possible is generally a good approach. > > I think using existing functions would be too limited, and Joe seems to > agree with this based on his experience. To be able to test corner cases > of the compiler/linker, such as LTO, we need special code patterns. > OTOH, if we want to use an existing kernel function for testing, it needs > to be relatively stable, i.e., not being changed very often. It is not always > easy to find some known to be stable code that follows specific patterns. > If we add dedicated code as test targets, things will be much easier > down the road. Fair enough. > > And a little bit of bikeshedding at the end. I think it would be more > > descriptive if the new config options and tests (test modules) have > > klp-build somewhere in the name to keep it clear. What do you think? > > Technically, we can also use these tests to test other toolchains, for > example, kpatch-build. I don't know ksplice or kGraft enough to tell > whether they can benefit from these tests or not. OTOH, I am OK > changing the name/description of these config options. I would prefer it, thank you. Unless someone else objects of course. Regards, Miroslav
