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

[Willy Tarreau]

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.

Thanks!
Willy