linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
To: Mark Brown <broonie@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Vlastimil Babka <vbabka@suse.cz>, Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>, Shuah Khan <shuah@kernel.org>,
	Jason Gunthorpe <jgg@ziepe.ca>, Leon Romanovsky <leon@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH] selftests/mm: Have the harness run each test category separately
Date: Fri, 23 Jan 2026 12:45:19 +0000	[thread overview]
Message-ID: <3f345966-37e2-457b-a917-1f0d4726d669@lucifer.local> (raw)
In-Reply-To: <56e2d214-fe48-48b0-88a2-287294520cb4@sirena.org.uk>

On Fri, Jan 23, 2026 at 12:35:06PM +0000, Mark Brown wrote:
> On Fri, Jan 23, 2026 at 12:09:52PM +0000, Lorenzo Stoakes wrote:
> > On Fri, Jan 23, 2026 at 11:21:39AM +0000, Mark Brown wrote:
> > > On Thu, Jan 22, 2026 at 07:13:06PM +0000, Lorenzo Stoakes wrote:
>
> > > > # IMPORTANT: If you add a new test CATEGORY please add a simple wrapper
> > > > # script so kunit knows to run it, and add it to the list below.
> > > > # If you do not YOUR TESTS WILL NOT RUN IN THE CI.
>
> > > Is the Makefile the place for that or run_vmtests.sh?  You don't need to
> > > edit the Makefile to add a category.
>
> > As I said, you have to edit the Make file to _add a new test_.
>
> > The point being you will necessarily see this. It'd be fairly odd to add a new
> > category without adding a new test.
>
> You do, but adding the category is actually done in run_vmtests.sh and I
> can see someone doing something like adding the test to the Makefile to
> build the test while still developing it, then going back and hooking it
> up to run_vmtests.sh when they're satisfied that things work and
> deciding at that point that it doesn't fit with any of the existing
> categories.

Right sure, so maybe worth putting in both.

All of this is pretty icky but it's important to get this running ASAP and live
with the ick for now, we can do something better later.

>
> > And since you'd need to update the Makefile, putting this comment at the top of
> > the file immediately next to where you have to put it makes sense.
>
> I guess.  At the top of the Makefile or right next to where you have to
> add the tests?  There's about 50 lines of setup at the top of the
> Makefile before you get to all the TEST_GEN_FILES.

I'd say right at the top, for both run_vmtests.sh and the Makefile, thanks.

>
> > > > > +TEST_PROGS += ksft_vmalloc.sh
>
> > > > Is this something that only kunit will interpret, or will it impact the
> > > > build in any other way?
>
> > > KUnit isn't involved here?  This is just how you specify which programs
> > > are run by kselftest, this is a Makefile in the kselftest framework.
>
> > s/kunit/kselftest/.
>
> > I use the mm selftests locally by running sudo ./run_vmtests.sh directly. So I
> > don't know how TEST_GEN_PROGS interacts with anything else.
>
> If you're not invoking any of the kselftest infrastructure it's not
> going to do anything, nothing execept make looks at the Makefile.  When
> you do a build it'll result in the specified binary being built (and
> installed if you ask for that) but not otherwise interacted with by the
> generic framework.  See:
>
>    https://docs.kernel.org/dev-tools/kselftest.html
>
> for the various variables that the build system has for suite Makefiles.

Ack thanks!

Cheers, Lorenzo


      reply	other threads:[~2026-01-23 12:45 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-20 13:25 Mark Brown
2026-01-20 17:22 ` Andrew Morton
2026-01-20 17:47   ` Mark Brown
2026-01-22 19:13 ` Lorenzo Stoakes
2026-01-23 11:21   ` Mark Brown
2026-01-23 12:09     ` Lorenzo Stoakes
2026-01-23 12:35       ` Mark Brown
2026-01-23 12:45         ` Lorenzo Stoakes [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3f345966-37e2-457b-a917-1f0d4726d669@lucifer.local \
    --to=lorenzo.stoakes@oracle.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=david@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=leon@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.com \
    --cc=rppt@kernel.org \
    --cc=shuah@kernel.org \
    --cc=surenb@google.com \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox