On Fri 2022-07-01 16:13:50, Shuah Khan wrote: > On 7/1/22 1:48 AM, Miroslav Benes wrote: > > 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. > > Yes I did and after reviewing and thinking about it some more, I decided this > is the right direction go down on. Do you have some particular reason why building modules in selftests directory might cause problems, please? IMHO, the reason that the test modules are in lib is because the modules were there before selftests. Developers historically loaded them manually or they were built-in. Selftest were added later and are just another way how the module can be loaded. This is the case, for example, for lib/test_printf.c. Otherwise, I do not see any big difference between building binaries and modules under tools/tests/selftests. As I said, in the older thread, IMHO, it makes more sense to have the selftest sources self-contained. There actually seems to be a principal problem in the following use case: --- cut Documentation/dev-tools/kselftest.rst --- Kselftest from mainline can be run on older stable kernels. Running tests from mainline offers the best coverage. Several test rings run mainline kselftest suite on stable releases. The reason is that when a new test gets added to test existing code to regression test a bug, we should be able to run that test on an older kernel. Hence, it is important to keep code that can still test an older kernel and make sure it skips the test gracefully on newer releases. --- cut Documentation/dev-tools/kselftest.rst --- together with --- cut Documentation/dev-tools/kselftest.rst --- * First use the headers inside the kernel source and/or git repo, and then the system headers. Headers for the kernel release as opposed to headers installed by the distro on the system should be the primary focus to be able to find regressions. --- cut Documentation/dev-tools/kselftest.rst --- It means that selftests should support running binaries built against newer kernel sources on system running older kernel. But this might be pretty hard to achieve and maintain. The normal kernel rules are exactly the opposite. Old binaries must be able to run on newer kernels. The old binaries were built against older headers. IMHO, the testing of stable kernels makes perfect sense. And if we want to support it seriously than we need to allow building new selftests against headers from the old to-be-tested kernel. And it will be possible only when the selftests sources are as much selfcontained as possible. Does this makes any sense, please? Best Regards, Petr
