From: Willy Tarreau <w@1wt.eu>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] selftests/nolibc: always rebuild the sysroot when running a test
Date: Thu, 27 Oct 2022 04:34:56 +0200 [thread overview]
Message-ID: <20221027023456.GA26215@1wt.eu> (raw)
In-Reply-To: <20221026204138.GQ5600@paulmck-ThinkPad-P17-Gen-1>
On Wed, Oct 26, 2022 at 01:41:38PM -0700, Paul E. McKenney wrote:
> > > I have queued this. I expect to push this into the next merge window,
> > > thus avoiding the need to document the need for "make clean" in my
> > > pull request. ;-)
> >
> > Stupid question, is it really worth postponing it, considering that
> > we've just introduced this series right now ? I mean, if the current
> > usage is confusing, it's probably better to propose the fix before
> > 6.1-final ? It's not a new feature here but rather a fix for a recently
> > introduced one, thus I think it could be part of the next fix series.
> > Rest assured I don't want to put a mess into your patch workflow, just
> > asking :-)
>
> You lost me here.
Ah sorry!
> My intent is to push these nolicb patches into the upcoming v6.2
> merge window:
>
> 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12
> 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation
> e1bbfe393c900 selftests/nolibc: Add 7 tests for memcmp()
> 3f2c1c45a3a9a selftests/nolibc: Always rebuild the sysroot when running a test
>
> I didn't see the problem until I queued the third patch (e1bbfe393c900),
> and it is still in -rcu, not in v6.1.
>
> What am I missing here?
I thought that since some of them are fixes, they would be pushed during
6.1-rc so that we don't release 6.1 with known defects. For example Rasmus'
fix for memcmp() or the strlen() fix would IMHO make sense for this
release since we're aware of the bugs and we have the fixes. The 3rd one
is indeed an addition and in no way a fix and it can easily wait for 6.2.
The 4th one is more of a usability fix but I agree that for this last one
it's debatable, I was mostly seeing this as a possiility to avoid causing
needless confusion.
Hoping this clarifies my initial question.
Thanks,
Willy
next prev parent reply other threads:[~2022-10-27 2:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-26 5:45 [PATCH] selftests/nolibc: always rebuild the sysroot when running a test Willy Tarreau
2022-10-26 16:48 ` Paul E. McKenney
2022-10-26 19:59 ` Willy Tarreau
2022-10-26 20:41 ` Paul E. McKenney
2022-10-27 2:34 ` Willy Tarreau [this message]
2022-10-27 17:04 ` Paul E. McKenney
2022-10-27 17:13 ` Willy Tarreau
2022-10-27 18:26 ` Paul E. McKenney
2022-10-28 19:34 ` Willy Tarreau
2022-10-28 22:22 ` Paul E. McKenney
2022-10-29 5:11 ` 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=20221027023456.GA26215@1wt.eu \
--to=w@1wt.eu \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox