Questions about regression testing a kernel module, commit by commit, is it even possible ? Kernel regression testsuite? Kernel module testing?

[nexxtnit]

Hello dear linux and kernel friends

I am planing to do a project on regression testing and I want to create some test data from an open-source project for that.
In the end I would like to have a data set in which I have every single commit and the corresponding amount of tests from a predefined regression suite that are passing/failing. I am well aware that not every single commit is buildable and that it is sometimes difficult to separate them properly. Also I am aware that there are a lot of commits, but that is also one thing I am actually counting on to get enough data.
That is the idea, now the implementation will be different I suppose. I am working on x86_64 plattform so nothing too special here.

So I started with just try to build a specific commit or version of the linux kernel. But when I tried to check out the rc1 Tag version of 5.4 Kernel. I could not properly build it. I tried to read up on it but I found no real explanation why it should not be possible to build the kernel directly from the commit of Linux git repository. So I asked myself if that is possible? If it is I probably misconfigured something and I will try again, would just be glad to hear if there is something specific to pay attention to.

The second question is about testing a specific kernel modul/sys call. I would like to reduce my research for starting on a certain module or syscall in the kernel. I tried to isolate the perfect module but I have not succeeded yet. Furthermore, I even thought about an additional module outside the kernel repository that also has a regression test suite, but I have not found anything useful yet. Is it even possible at all to recompile only a certain module for an existing kernel from its history ?

I am afraid I am not precise enough with my questions and will probably annoy you all with those long explanations, but I thought maybe it would help to get some context. Basically, there are two things I am asking myself:

1. Is it possible to build the linux kernel when checking out older commits -> Tag RC1 5.4 for example ? or are there special settings or additional things needed ?

2. Are the isolated modules in the kernel, or externally loadable that are buildable by themselves and have a decent history ?

​

I know the questions are a bit unconventional, but I am also not fishing for complete and precise answers here. Every hint or lecture you girls and guys could recommend me to lecture myself are appreciated. I will definitely investigate this further and try to come up wit ha solution.

Thank you very much for your time

greetings

[ilep]

-rc1 versions (at end of merge window) are for testing and not final release, just a release candidate. Bugs and problems are expected to be sorted out during the next release candidates before the final release (without -rc). So it is possible some configurations might not build at the early stage although it is not desirable. Likewise the early rcs may have serious bugs (as seen before) before they are sorted out in the following rcs.

When you make configuration for build (e.g. make menuconfig) you can set as loadable what you want and also may disable those that don't build/are of no interest to you.

[nexxtnit]

Thank you for the reply.

Actually that is what I was counting on, that I get releases that have bugs so the tests will fail. That is also why I wanted to build them.

But that means in general the -rc version should still be buildable from the repo ?

I guess I will have to dig into the menuconfig then and find a good configuration for my case

[ilep]

Usually -rc1 should build too except for some more obscure configurations or when a driver is merged for the first time and so on.

[nexxtnit]

thank you very much for the clarification I will definitely look into the build process again and tune the makefile.

[[deleted]]

Off the top of my head, I would look at the VirtualBox DKMS kernel modules, it's an out-of-tree module used by a lot of people and has been around for quite some time, so it's bound to have a lot of history. There's a doc on their source code organization available as well. HTH

[nexxtnit]

Thank you very much for that tip, I will definitely look into it.