* Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> [250130 09:25]: > Hi Liam, Hi Geert, I'd like to say sorry for getting upset about this. > > On Thu, 30 Jan 2025 at 15:06, Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > > > > I'll await your patch to link all this together. Please Cc the authors. > > I gave it a try for kselftests a few years ago. > https://lore.kernel.org/all/20190114135144.26096-1-geert+renesas@xxxxxxxxx > Unfortunately only one patch was applied... It is difficult to integrate the test framework due to the nature of it stubbing out a lot of the kernel code it uses. This is also a strength as it can be used to test unlikely failure scenarios that are difficult or impossible to recreate in kunit or a running kernel - even with injections of failures. It can also be used to isolate issues for recreating, which is very valuable in larger, longer running issues. I also use the userspace testing to test rcu using threads and I think that would be even more challenging on a booted system. > > > > > it is to get m68k to build, you should probably know how to read a > > > > makefile. > > > > > > Like all other kernel cross-compilation? Usually you don't even have > > > to know where your cross-compiler is living: > > > > > > make ARCH=m68k > > > > Ignoring that I had to make a config - which asked challenging > > questions... > > make ARCH=m68k defconfig That also prompts, defoldconfig did not. > > > And ignoring the steps to get m68k compiler... > > apt install gcc-m68k-linux-gnu? There are a few compilers, multilib or such? I've had issues with getting all the archs working for cross compile on the same machine (arm, arm64, riscv, m68k, ppc, ppc64, parisc). > > > > > > When trying the above, and ignoring failures due to missing packages > > > > > on my host: > > > > > - there are several weird build errors, > > > > > - this doesn't play well with O=, > > > > > - lots of scary warnings when building for 32-bit, > > > > > - ... > > > > > > > > > In file included from ./include/linux/sched.h:12, > > from arch/m68k/kernel/asm-offsets.c:15: > > ./arch/m68k/include/asm/current.h:7:30: error: invalid register name for ‘current’ > > 7 | register struct task_struct *current __asm__("%a2"); > > Which compiler are you using? I've had a hard time getting m68k to boot in qemu because of the lack of userspace. I use m68k for nommu testing, but have a hard time getting the buildroot to work correctly to build what I need. This was a grumpy, pre-coffee way of saying that some tasks are not straight forward and are extremely difficult to make straight forward. Sorry, I should not have made such rash comments. I respect you and your work and appreciate the help you have given me in the past. I would also like to thank you for your earlier statements. After rereading them, I believe I misunderstood what you were saying. I've been trying to make these tests a part of automatic testing somehow, even getting them to run in userspace. > > > > > > At least the kunit tests build (and run[1] ;-) most of the time... > > > > > > > > Do they? How about you break something in xarray and then try to boot > > > > the kunit, or try to boot to load that module. > > > > > > If you break the kernel beyond the point of booting, you can indeed > > > not run any test modules... > > > > Which is extremely easy when you are changing code that runs so early in > > the boot. > > > > My code found a compiler issue because it's the first function that > > returns a boolean. This is stupid. > > Sorry. I don't understand this comment. I had a bug a few years ago that turned out to be a clang compiler issue with booleans. It turns out my code was the first function to return a boolean and that wasn't being properly handled by the compiler (thanks to mitigation of clearing registers with certain .config/compiler flags).. it's not important. More importantly, I think I get your point, you think that the testing should be integrated and complain if it's broken - at least by bots. I don't think this is practical in all cases, unfortunately. Although I would like to strive for this - and I do by keeping any tests I can as a kernel module while keeping the harder to recreate issues as user space. I think we do a good job keeping testing up to date and adding testcases as new issues are discovered. Thanks, Liam
