Message-ID: <9636ed9d-3bfb-4dda-98dc-f945c9d53698@lucifer.local>
Date: Thu, 30 Jan 2025 14:09:04 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Geert Uytterhoeven <geert@...ux-m68k.org>
Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        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,

Having written a ton of test code, I've unfortunately encountered a lot of
this sort of push-back and it's HUGELY off-putting. Writing test code
should be ENCOURAGED not litigated against.

The truth is far too little kernel code is tested to any degree, and this
is part of why.

On kunit collaboration, I attended an in-person talk at LPC on kunit
userland testing where it was broadly agreed that at this point in time,
the xarray/radix tree tests weren't really suited to the framework.

Therefore I think the healthy means of pushing forward with integration is
in sensible discussion and if patches, RFC patches in collaboration with
authors.

The unhealthy approach is to needle one of the biggest contributors to core
test code in the kernel on a thread because you don't seem to want to cd to
a directory and run make.

Why is this relevant to me? I am the author of the VMA test suite, on which
I spent countless hours + relied heavily on Liam's work to do so, and
equally there you have to cd to a directory and run make.

But at the same time in both cases, testability of key internal components
is ENORMOUSLY improved and allows for REALLY exciting possibilities in test
coverage, really isolating functions for unit testing, enormously fast
iteration speed, etc. etc.

I ask you to weigh up the desire to enumerate your misgivings about the
testing approach used here vs. all of the above.

I would respectfully suggest that here is neither the time nor the place
for splitting hairs.

Thanks, Lorenzo

On Thu, Jan 30, 2025 at 02:25:57PM +0100, Geert Uytterhoeven wrote:
> Hi Liam,
>
> On Thu, 30 Jan 2025 at 13:52, Liam R. Howlett <Liam.Howlett@...cle.com> wrote:
> > * Geert Uytterhoeven <geert@...ux-m68k.org> [250130 03:21]:
> > > On Wed, 29 Jan 2025 at 23:26, Liam R. Howlett <Liam.Howlett@...cle.com> 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?
>
> > 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...
>
> 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
>
> > > 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,
> > >   - ...
> > >
> > > 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 does _not_ mean the userspace tests are not useful, and that I
> approve breaking the userspace tests...
>
> [1] https://lore.kernel.org/all/CAK7LNASdA+5_pdTjr1dY-cKGSDq804Huc_CX_8-Gg+ypFCmajQ@mail.gmail.com/
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
>
> 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

Powered by blists - more mailing lists