Hi Geert, On 2026-01-06 14:36:23+0100, Geert Uytterhoeven wrote: > On Tue, 6 Jan 2026 at 12:47, Thomas Weißschuh <[email protected]> wrote: > > On 2026-01-06 12:40:12+0100, Geert Uytterhoeven wrote: > > > On Sun, 4 Jan 2026 at 23:14, Thomas Weißschuh <[email protected]> > > > wrote: > > > > (...) > > > > > > --- a/tools/testing/selftests/nolibc/Makefile.nolibc > > > > +++ b/tools/testing/selftests/nolibc/Makefile.nolibc > > > > @@ -117,7 +117,7 @@ DEFCONFIG_riscv32 = rv32_defconfig > > > > DEFCONFIG_riscv64 = defconfig > > > > DEFCONFIG_s390x = defconfig > > > > DEFCONFIG_loongarch = defconfig > > > > -DEFCONFIG_sparc32 = sparc32_defconfig > > > > +DEFCONFIG_sparc32 = sparc64_defconfig > > > > > > How can we test sparc32 using a 64-bit kernel? > > > > CONFIG_COMPAT=y > > FWIW, testing 32-bit userland on a 64-bit kernel is something completely > different...
I can't really follow. We are testing the userspace nolibc here and assume that the kernel component already works correctly. Whether that is a native 32-bit kernel, 64-bit kernel with CONFIG_COMPAT=y or even qemu-user-sparc doesn't really matter in my opinion. What am I missing? > > Please note that this changed in (the now committed) v2 anyways: > > https://lore.kernel.org/lkml/[email protected]/ > > Sorry, I hadn't noticed the newer version, as the latter does not > include some keywords to trigger my interest ;-) Now I am left wondering about the specific keyword that triggered on v1 but not v2 :-) Thomas
