All of lore.kernel.org
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/nolibc: add 7 tests for memcmp()
Date: Fri, 21 Oct 2022 19:20:26 +0200	[thread overview]
Message-ID: <20221021172026.GC8420@1wt.eu> (raw)
In-Reply-To: <20221021170738.GM5600@paulmck-ThinkPad-P17-Gen-1>

On Fri, Oct 21, 2022 at 10:07:38AM -0700, Paul E. McKenney wrote:
> > I see. In the worst case, a preliminary "make clean" will do it. We just
> > need to decide what's the best solution for everyone (i.e. not waste too
> > much time between tests while not getting misleading results by accident).
> 
> Maybe just document the careful/slow way, then people doing it more
> frequently can do it the clever/fast way.
> 
> My guess is that the careful/slow is this:
> 
> 	pushd tools/include/nolibc
> 	make clean
> 	make
> 	popd
> 	pushd tools/testing/selftests/nolibc
> 	make clean
> 	make -j32 run
> 
> Or did I miss a turn in there somewhere?

It's even easier, you don't even need the clean phase in include/nolibc.
I'm doing this and it's sufficient:

  make -C tools/testing/selftests/nolibc clean
  make -C tools/testing/selftests/nolibc nolibc-test
  tools/testing/selftests/nolibc/nolibc-test

Or for the test under QEMU, which involves a kernel build:

  make -C tools/testing/selftests/nolibc clean
  make -C tools/testing/selftests/nolibc -j $(nproc) run

Where would you first look for such a hint ? Maybe the help output of
the default "make" command could send as a hint that a clean is needed
after patching nolibc and that could be sufficient ? I just want to make
sure users don't waste their time trying to find what they could be doing
wrong.

Willy

  reply	other threads:[~2022-10-21 17:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-21  6:03 [PATCH] selftests/nolibc: add 7 tests for memcmp() Willy Tarreau
2022-10-21 15:56 ` Paul E. McKenney
2022-10-21 17:01   ` Willy Tarreau
2022-10-21 17:07     ` Paul E. McKenney
2022-10-21 17:20       ` Willy Tarreau [this message]
2022-10-21 18:00         ` Paul E. McKenney
2022-10-22 11:22           ` Willy Tarreau
2022-10-24 15:53             ` Paul E. McKenney
2022-10-26  5:39               ` Willy Tarreau
2022-10-26  9:08                 ` Rasmus Villemoes
2022-10-26 19:52                   ` Willy Tarreau
2022-10-27  9:09                     ` Rasmus Villemoes
2022-10-27 17:20                       ` Willy Tarreau
2022-10-26 13:57                 ` Paul E. McKenney
2022-10-26 14:17                   ` Willy Tarreau

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=20221021172026.GC8420@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=paulmck@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.