Open KOLANICH opened 1 year ago
Thank you for reporting this. Those changes you suggest would hide the problem, which I'm not sure is the best thing to do, especially considering that it'd take some effort and add complexity (and perhaps bugs, too). My current thinking is that if you choose to install an RT kernel, you should uninstall LKRG. Why would you want to keep LKRG installed when it's not working? If we silence the problem, someone could think that LKRG is working when it is not, which would be worse than the current problem.
So I'm leaning towards leaving things as they are, and counting your report as a vote for us to consider supporting RT kernels (which is not currently planned).
My current thinking is that if you choose to install an RT kernel, you should uninstall LKRG. Why would you want to keep LKRG installed when it's not working?
I suppose a reason would be if you also have non-RT kernel(s) installed and would at least sometimes boot into them and want LKRG loaded into them. OK, that's reasonable. I wonder if there's a DKMS-level way to specify that a module is only for a subset of kernel versions, e.g. with a regexp. Any DKMS experts here? @morfikov
There's BUILD_EXCLUSIVE_KERNEL, but I've never played with it. It looks like it's what you want: https://manpages.debian.org/unstable/dkms/dkms.8.en.html
There's BUILD_EXCLUSIVE_KERNEL
I think we need the opposite of it, or else we need to somehow encode that negation in a regexp. Also, I expect the kernel version strings for (non-)RT kernels to vary between distros, whereas what we include here should be generic. Worse, the (non-)RT property might not even be included in there.
For example, if lkrg is installed and then one installs a
PREEMPT_RT
kernel usingapt
, then the package manager hook building dkms packages will fail. Then it will try to execute this hook again and again before every action, like removing thePREEMPT_RT
kernel packages. A workaround is to comment the lines causing the error and let the hooks work. I wonder if there is a better way to handle it, such exclude this module from being built if it is tried to be built for an RT kernel. Or maybe, if there is no a proper way, just build a dummy module, or maybe only build the features not interferring with realtimeness.