Re: [PATCH] selftests/nolibc: always rebuild the sysroot when running a test

[Paul E. McKenney]

On Thu, Oct 27, 2022 at 07:13:08PM +0200, Willy Tarreau wrote:
> On Thu, Oct 27, 2022 at 10:04:53AM -0700, Paul E. McKenney wrote:
> > > > 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.
> > 
> > Very much so, thank you!
> > 
> > I was not considering the bug fixed by the first two patches to be
> > serious, my mistake, apologies for my misclassification.
> 
> No worries, I wasn't probably clear upfront about the purpose.
> 
> > Given that background, I would rebase these two, test them, and send
> > off a pull request, probably early next week.
> > 
> > 2318a710bffbd tools/nolibc: Fix missing strlen() definition and infinite loop with gcc-12
> > 6937b8de8f1c3 tools/nolibc/string: Fix memcmp() implementation
> 
> Perfect, thank you!
> 
> > I would push the other two commits into the upcoming merge window.
> 
> OK!
> 
> > Or might the discussion between you and Rasmus result in changes to
> > either of those first two commits?  If so, I should of course wait for
> > that discussion to resolve.
> 
> We'll see, but in any case it would just be a minor detail, but I'll
> give you a quick response so that you don't have to deal with multiple
> versions of the patch, we all know that it's painful.

If I don't hear otherwise from you by the end of tomorrow (Friday),
Pacific Time, I will rebase those two patches in preparation for sending
a pull request for the regression.  I will of course run the pull-message
text past you before sending the pull request.

							Thanx, Paul