Messages in this thread | | | Date | Mon, 9 Oct 2023 09:18:47 -0700 | From | "Paul E. McKenney" <> | Subject | Re: nolibc changes since 6.6-rc1 for linux-next |
| |
On Mon, Oct 09, 2023 at 01:25:58PM +0200, Thomas Weißschuh wrote: > 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.
Pulled, and thank you!
> 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
And the tests pass for me as above for "make run" and with 158 passing and one skipped for "make run-user".
> 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.
And it is doing its job here, thank you! ;-)
Thanx, Paul
| |