Re: nolibc changes since 6.6-rc1 for linux-next

[Thomas Weißschuh]

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