Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.35 as permitted sender) client-ip=23.128.96.35;
Date:   Mon, 9 Oct 2023 13:25:58 +0200
From:   Thomas =?utf-8?Q?Wei=C3=9Fschuh?= <linux@weissschuh.net>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     Willy Tarreau <w@1wt.eu>, Shuah Khan <skhan@linuxfoundation.org>,
        Shuah Khan <shuah@kernel.org>, linux-kernel@vger.kernel.org
Subject: Re: nolibc changes since 6.6-rc1 for linux-next
Message-ID: <cfd43fe2-41db-41e1-be43-87755f7b7cce@t-8ch.de>
References: <11a790c0-f9c0-49eb-b14f-56b962af6d2d@t-8ch.de>
 <dcfa99da-eb3e-4c85-9e7f-092bbb1be801@linuxfoundation.org>
 <48c01af3-d373-4546-a8f2-d81fa447eaaa@t-8ch.de>
 <25382680-956a-4612-b930-f6823c71cf8d@paulmck-laptop>
 <696fc488-63d3-444c-a9f2-14d7a7379143@linuxfoundation.org>
 <23bc3841-4cda-4a23-a67f-a944e1104f1d@paulmck-laptop>
 <20231007070630.GB20998@1wt.eu>
 <d80c1da1-56f8-4b94-b1e2-eef75a52d022@paulmck-laptop>
 <fad7814f-0bbd-43f0-a205-9ba2c08bac22@t-8ch.de>
 <76a51116-46bb-4271-b5ac-c101e02d5a63@paulmck-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <76a51116-46bb-4271-b5ac-c101e02d5a63@paulmck-laptop>
Precedence: bulk

On 2023-10-08 09:27:43-0700, Paul E. McKenney wrote:

> [..]

> The other approach involves rebasing the "nolibc/next" stack
> on top of the "nolibc/fixes" stack.  Please see the -rcu branch
> nolibc-rebase.2023.10.08a to see how that would look.  Note that the
> rebase process detected and eliminated the duplicate commits.
> In this case, I actually used "git cherry-pick":
> 
> 	git checkout -b nolibc-rebase.2023.10.08a nolibc/fixes
> 	git cherry-pick v6.6-rc1..nolibc/next
> 	git cherry-pick skip # After complaint about first duplicate
> 	git cherry-pick --continue
> 	git cherry-pick skip # After complaint about second duplicate
> 	git cherry-pick --continue
> 	git diff nolibc-merge.2023.10.08a # Verify no differences
> 
> You could just as easily do this:
> 
> 	git branch nolibc-rebase.2023.10.08a nolibc/next
> 	git rebase --onto nolibc/next v6.6-rc1 nolibc-rebase.2023.10.08a
> 
> There would be the same complaints about duplicate commits and
> similar response (it prompts you with your alternatives).
> 
> And then I send the fixes portion of the branch to Linus after a few
> days of exposure to -next testing, and the full branch for the upcoming
> merge window.
> 
> Test results for nolibc-rebase.2023.10.08a:
> "make run": 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> "make run-user": 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> 
> This approach has its strenghts and weaknesses.
> 
> 1.	It avoids all the weaknesses called out for merging.
> 
> 2.	It can require more testing when moving yet another commit
> 	down into urgent-fixes portion of the branch.
> 
> 3.	Many people are much less comfortable rebasing and mass
> 	cherry-picking than they are with merging.
> 
> Again, I am happy to do this either way (especially since I now have
> both ways set up in -rcu), but felt the need to call out the strengths
> and weaknesses of each approach.  Your guys' choice.

Your proposed aproach sounds great, thanks for all your patience.

I implemented it now at
https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git/

Please pull the changes in this repository since the v6.6-rc1 tag.

The branch 'fixes' up to and including
5579b93524ab2d360e2250bdd12ba32635a4300b for the v6.6 cycle.

The branch 'next' up to and including
d423dcd4ac21041618ab83455c09440d76dbc099 for linux-next.

The branch 'next', based upon 'fixes', was tested as follows:

i386:          160 test(s): 160 passed,   0 skipped,   0 failed => status: success
x86_64:        160 test(s): 160 passed,   0 skipped,   0 failed => status: success
arm64:         160 test(s): 160 passed,   0 skipped,   0 failed => status: success
arm:           160 test(s): 160 passed,   0 skipped,   0 failed => status: success
mips:          160 test(s): 159 passed,   1 skipped,   0 failed => status: warning
ppc:           160 test(s): 160 passed,   0 skipped,   0 failed => status: success
ppc64:         160 test(s): 160 passed,   0 skipped,   0 failed => status: success
ppc64le:       160 test(s): 160 passed,   0 skipped,   0 failed => status: success
riscv:         160 test(s): 160 passed,   0 skipped,   0 failed => status: success
s390:          160 test(s): 159 passed,   1 skipped,   0 failed => status: warning
loongarch:     160 test(s): 159 passed,   1 skipped,   0 failed => status: warning

> While in the area, would the following (absolutely not urgent or even
> particularly important) patch be a good idea?  This gets rid of a line
> of noise from "git status" after running the tests.
> 
> 							Thanx, Paul
> 
> ------------------------------------------------------------------------
> 
> diff --git a/tools/testing/selftests/nolibc/.gitignore b/tools/testing/selftests/nolibc/.gitignore
> index 52f613cdad54..3487da96e12e 100644
> --- a/tools/testing/selftests/nolibc/.gitignore
> +++ b/tools/testing/selftests/nolibc/.gitignore
> @@ -3,3 +3,4 @@
>  /nolibc-test
>  /run.out
>  /sysroot/
> +/initramfs.cpio

Thanks, I folded this into commit
fdaa5901424c ("selftests/nolibc: don't embed initramfs into kernel image"),
where it belongs.

Thomas