Hi Liam, On Thu, 30 Jan 2025 at 15:06, Liam R. Howlett <Liam.Howlett@xxxxxxxxxx> wrote: > * Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> [250130 08:26]: > > 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? > ^^^^^^^^^^^^^^^^^^^^^^^ Things like "make -C drivers/net/ethernet/" stopped working ca. 20y ago. > > > 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. 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 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 > And ignoring the steps to get m68k compiler... apt install gcc-m68k-linux-gnu? > > > > 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? > > > > 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. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
