Re: [PATCH] xarray: port tests to kunit

["Liam R. Howlett" <Liam.Howlett@oracle.com>]

* Geert Uytterhoeven <geert@linux-m68k.org> [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@oracle.com> 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@glider.be
> 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