* Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> [250130 08:26]:
> Hi Liam,
>
> On Thu, 30 Jan 2025 at 13:52, Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote:
> > * Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> [250130 03:21]:
> > > On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote:
> > > > I've never used the kunit testing of xarray and have used the userspace
> > > > testing instead, so I can't speak to the obscure invocation as both
> > > > commands seem insanely long and obscure to me.
> > >
> > > The long and obscure command line is a red herring: a simple
> > > "modprobe test_xarray" is all it takes...
> >
> > That command worked before too...
>
> Exactly, great!
>
> > > > You should look at the userspace testing (that this broke) as it has
> > > > been really useful in certain scenarios.
> > >
> > > BTW, how do I even build tools/testing/radix-tree?
> > > "make tools/help" doesn't show the radix-tree test.
> > > "make tools/all" doesn't seem to try to build it.
> > > Same for "make kselftest-all".
> >
> > make
>
> Where?
> > > BTW, how do I even build tools/testing/radix-tree?
^^^^^^^^^^^^^^^^^^^^^^^
>
> > Or look at the make file and stop guessing. Considering how difficult
>
> There is no Makefile referencing tools/testing/radix-tree or the
> radix-tree subdir. That's why I asked...
>
> Oh, I am supposed to run make in tools/testing/radix-tree/?
> What a surprise!
>
> Which is a pain when building in a separate output directory, as you
> cannot just do "make -C tools/testing/radix-tree" there, but have to
> type the full "make -C tools/testing/radix-tree O=..." (and optionally
> ARCH=... and CROSS_COMPILE=...; oh wait, these are ignored :-( in the
> source directory instead...
I'll await your patch to link all this together. Please Cc the authors.
>
> If these tests are not integrated into the normal build system (see
> also [1]), I am not so surprised the auto-builders don't build them,
> and breakages are introduced...
>
> > 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...
And ignoring the steps to get m68k compiler...
> > > 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");
>
> > > 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.
>
> Which does _not_ mean the userspace tests are not useful, and that I
> approve breaking the userspace tests...
Perfect, let's revert the patch then.
This is such a waste of time.
