* 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
