* 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.
