[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ihl4bxs65uphmepoyw4xoa26mr4f3gci2mgtoq4osrzeyh3mup@hww2utbkxkfn>
Date: Thu, 30 Jan 2025 10:16:18 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: Sidhartha Kumar <sidhartha.kumar@...cle.com>, akpm@...ux-foundation.org,
christophe.leroy@...roup.eu, justinstitt@...gle.com,
linux-kernel@...r.kernel.org, linux-m68k@...ts.linux-m68k.org,
linuxppc-dev@...ts.ozlabs.org, llvm@...ts.linux.dev,
maddy@...ux.ibm.com, morbo@...gle.com, mpe@...erman.id.au,
nathan@...nel.org, naveen@...nel.org, ndesaulniers@...gle.com,
npiggin@...il.com, Matthew Wilcox <willy@...radead.org>,
linux-mm@...ck.org
Subject: Re: [PATCH] xarray: port tests to kunit
* Geert Uytterhoeven <geert@...ux-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@...cle.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
Powered by blists - more mailing lists