mbox series

nolibc changes since 6.6-rc1 for linux-next

Message ID 11a790c0-f9c0-49eb-b14f-56b962af6d2d@t-8ch.de
State New
Headers
Series nolibc changes since 6.6-rc1 for linux-next |

Pull-request

https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next

Message

Thomas Weißschuh Oct. 5, 2023, 5 p.m. UTC 
  Hi Shuah,

I'd like to test the current state of nolibc in linux-next.
Could pull the request below into your nolibc branch?

I'll do some manual tests this weekend, too.


Thanks,
Thomas


The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:

  Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next

for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:

  tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)

----------------------------------------------------------------
Ammar Faizi (5):
      tools/nolibc: i386: Fix a stack misalign bug on _start
      tools/nolibc: x86-64: Use `rep movsb` for `memcpy()` and `memmove()`
      tools/nolibc: x86-64: Use `rep stosb` for `memset()`
      tools/nolibc: string: Remove the `_nolibc_memcpy_down()` function
      tools/nolibc: string: Remove the `_nolibc_memcpy_up()` function

Thomas Weißschuh (9):
      tools/nolibc: add stdarg.h header
      selftests/nolibc: use -nostdinc for nolibc-test
      selftests/nolibc: libc-test: avoid -Wstringop-overflow warnings
      MAINTAINERS: nolibc: update tree location
      selftests/nolibc: don't embed initramfs into kernel image
      selftests/nolibc: allow building i386 with multiarch compiler
      tools/nolibc: avoid unused parameter warnings for ENOSYS fallbacks
      tools/nolibc: don't define new syscall number
      tools/nolibc: automatically detect necessity to use pselect6

 MAINTAINERS                                  |  2 +-
 tools/include/nolibc/Makefile                |  1 +
 tools/include/nolibc/arch-aarch64.h          |  3 --
 tools/include/nolibc/arch-i386.h             |  4 +-
 tools/include/nolibc/arch-loongarch.h        |  4 +-
 tools/include/nolibc/arch-riscv.h            |  3 --
 tools/include/nolibc/arch-x86_64.h           | 42 ++++++++++++++++++++
 tools/include/nolibc/nolibc.h                |  4 +-
 tools/include/nolibc/stdarg.h                | 16 ++++++++
 tools/include/nolibc/stdio.h                 |  3 +-
 tools/include/nolibc/string.h                | 36 +++++++-----------
 tools/include/nolibc/sys.h                   | 57 ++++++++++++++++------------
 tools/testing/selftests/nolibc/Makefile      | 45 +++++++++++++---------
 tools/testing/selftests/nolibc/nolibc-test.c |  6 +--
 14 files changed, 144 insertions(+), 82 deletions(-)
 create mode 100644 tools/include/nolibc/stdarg.h

Comments

Shuah Khan Oct. 5, 2023, 8:15 p.m. UTC | #1 
Hi Thomas,

On 10/5/23 11:00, Thomas Weißschuh wrote:
> Hi Shuah,
> 
> I'd like to test the current state of nolibc in linux-next.
> Could pull the request below into your nolibc branch?
> 
> I'll do some manual tests this weekend, too.
> 
> 
> Thanks,
> Thomas
> 
> 
> The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> 
>    Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> 
> are available in the Git repository at:
> 
>    https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next
> 
> for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> 
>    tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)

Absolutely. Do you mind tagging and pushing the tag and send
pull request with the tag?

thanks,
-- Shuah
Thomas Weißschuh Oct. 5, 2023, 8:28 p.m. UTC | #2 
On 2023-10-05 14:15:31-0600, Shuah Khan wrote:
> Hi Thomas,
> 
> On 10/5/23 11:00, Thomas Weißschuh wrote:
> > Hi Shuah,
> > 
> > I'd like to test the current state of nolibc in linux-next.
> > Could pull the request below into your nolibc branch?
> > 
> > I'll do some manual tests this weekend, too.
> > 
> > 
> > Thanks,
> > Thomas
> > 
> > 
> > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > 
> >    Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > 
> > are available in the Git repository at:
> > 
> >    https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next
> > 
> > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > 
> >    tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> 
> Absolutely. Do you mind tagging and pushing the tag and send
> pull request with the tag?

Sure, here it is:


The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:

  Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc-next.2023.10.05a

for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:

  tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)

----------------------------------------------------------------
nolibc updates for linux-next

----------------------------------------------------------------
Ammar Faizi (5):
      tools/nolibc: i386: Fix a stack misalign bug on _start
      tools/nolibc: x86-64: Use `rep movsb` for `memcpy()` and `memmove()`
      tools/nolibc: x86-64: Use `rep stosb` for `memset()`
      tools/nolibc: string: Remove the `_nolibc_memcpy_down()` function
      tools/nolibc: string: Remove the `_nolibc_memcpy_up()` function

Thomas Weißschuh (9):
      tools/nolibc: add stdarg.h header
      selftests/nolibc: use -nostdinc for nolibc-test
      selftests/nolibc: libc-test: avoid -Wstringop-overflow warnings
      MAINTAINERS: nolibc: update tree location
      selftests/nolibc: don't embed initramfs into kernel image
      selftests/nolibc: allow building i386 with multiarch compiler
      tools/nolibc: avoid unused parameter warnings for ENOSYS fallbacks
      tools/nolibc: don't define new syscall number
      tools/nolibc: automatically detect necessity to use pselect6

 MAINTAINERS                                  |  2 +-
 tools/include/nolibc/Makefile                |  1 +
 tools/include/nolibc/arch-aarch64.h          |  3 --
 tools/include/nolibc/arch-i386.h             |  4 +-
 tools/include/nolibc/arch-loongarch.h        |  4 +-
 tools/include/nolibc/arch-riscv.h            |  3 --
 tools/include/nolibc/arch-x86_64.h           | 42 ++++++++++++++++++++
 tools/include/nolibc/nolibc.h                |  4 +-
 tools/include/nolibc/stdarg.h                | 16 ++++++++
 tools/include/nolibc/stdio.h                 |  3 +-
 tools/include/nolibc/string.h                | 36 +++++++-----------
 tools/include/nolibc/sys.h                   | 57 ++++++++++++++++------------
 tools/testing/selftests/nolibc/Makefile      | 45 +++++++++++++---------
 tools/testing/selftests/nolibc/nolibc-test.c |  6 +--
 14 files changed, 144 insertions(+), 82 deletions(-)
 create mode 100644 tools/include/nolibc/stdarg.h


 Thanks,
 Thomas
Paul E. McKenney Oct. 5, 2023, 8:58 p.m. UTC | #3 
On Thu, Oct 05, 2023 at 10:28:05PM +0200, Thomas Weißschuh wrote:
> On 2023-10-05 14:15:31-0600, Shuah Khan wrote:
> > Hi Thomas,
> > 
> > On 10/5/23 11:00, Thomas Weißschuh wrote:
> > > Hi Shuah,
> > > 
> > > I'd like to test the current state of nolibc in linux-next.
> > > Could pull the request below into your nolibc branch?
> > > 
> > > I'll do some manual tests this weekend, too.
> > > 
> > > 
> > > Thanks,
> > > Thomas
> > > 
> > > 
> > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > 
> > >    Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > 
> > > are available in the Git repository at:
> > > 
> > >    https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next
> > > 
> > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > 
> > >    tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > 
> > Absolutely. Do you mind tagging and pushing the tag and send
> > pull request with the tag?
> 
> Sure, here it is:
> 
> 
> The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> 
>   Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc-next.2023.10.05a
> 
> for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> 
>   tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)

Looks good on my laptop:

make run:

	160 test(s): 160 passed,   0 skipped,   0 failed => status: success

make run-user:

	160 test(s): 158 passed,   2 skipped,   0 failed => status: warning

Shuah, I can take nolibc for the upcoming merge window (I believe that
it is my turn to do so), but if you would prefer to take them, that also
works for me.  Either way, just let me know.

							Thanx, Paul
Shuah Khan Oct. 5, 2023, 9:30 p.m. UTC | #4 
On 10/5/23 14:58, Paul E. McKenney wrote:
> On Thu, Oct 05, 2023 at 10:28:05PM +0200, Thomas Weißschuh wrote:
>> On 2023-10-05 14:15:31-0600, Shuah Khan wrote:
>>> Hi Thomas,
>>>
>>> On 10/5/23 11:00, Thomas Weißschuh wrote:
>>>> Hi Shuah,
>>>>
>>>> I'd like to test the current state of nolibc in linux-next.
>>>> Could pull the request below into your nolibc branch?
>>>>
>>>> I'll do some manual tests this weekend, too.
>>>>
>>>>
>>>> Thanks,
>>>> Thomas
>>>>
>>>>
>>>> The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
>>>>
>>>>     Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
>>>>
>>>> are available in the Git repository at:
>>>>
>>>>     https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next
>>>>
>>>> for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
>>>>
>>>>     tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
>>>
>>> Absolutely. Do you mind tagging and pushing the tag and send
>>> pull request with the tag?
>>
>> Sure, here it is:
>>
>>
>> The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
>>
>>    Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
>>
>> are available in the Git repository at:
>>
>>    https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc-next.2023.10.05a
>>
>> for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
>>
>>    tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> 
> Looks good on my laptop:
> 
> make run:
> 
> 	160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> 
> make run-user:
> 
> 	160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> 
> Shuah, I can take nolibc for the upcoming merge window (I believe that
> it is my turn to do so), but if you would prefer to take them, that also
> works for me.  Either way, just let me know.
> 

Yes it is your turn. Please go ahead and take them.

I will pull and do testing and update you on how it went.

thanks,
-- Shuah
Paul E. McKenney Oct. 6, 2023, 12:01 a.m. UTC | #5 
On Thu, Oct 05, 2023 at 03:30:52PM -0600, Shuah Khan wrote:
> On 10/5/23 14:58, Paul E. McKenney wrote:
> > On Thu, Oct 05, 2023 at 10:28:05PM +0200, Thomas Weißschuh wrote:
> > > On 2023-10-05 14:15:31-0600, Shuah Khan wrote:
> > > > Hi Thomas,
> > > > 
> > > > On 10/5/23 11:00, Thomas Weißschuh wrote:
> > > > > Hi Shuah,
> > > > > 
> > > > > I'd like to test the current state of nolibc in linux-next.
> > > > > Could pull the request below into your nolibc branch?
> > > > > 
> > > > > I'll do some manual tests this weekend, too.
> > > > > 
> > > > > 
> > > > > Thanks,
> > > > > Thomas
> > > > > 
> > > > > 
> > > > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > > > 
> > > > >     Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > > > 
> > > > > are available in the Git repository at:
> > > > > 
> > > > >     https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next
> > > > > 
> > > > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > > > 
> > > > >     tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > > > 
> > > > Absolutely. Do you mind tagging and pushing the tag and send
> > > > pull request with the tag?
> > > 
> > > Sure, here it is:
> > > 
> > > 
> > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > 
> > >    Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > 
> > > are available in the Git repository at:
> > > 
> > >    https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc-next.2023.10.05a
> > > 
> > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > 
> > >    tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > 
> > Looks good on my laptop:
> > 
> > make run:
> > 
> > 	160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> > 
> > make run-user:
> > 
> > 	160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> > 
> > Shuah, I can take nolibc for the upcoming merge window (I believe that
> > it is my turn to do so), but if you would prefer to take them, that also
> > works for me.  Either way, just let me know.
> 
> Yes it is your turn. Please go ahead and take them.

Very good, I will merge them in and post them to the relevant email lists.

> I will pull and do testing and update you on how it went.

Looking forward to seeing what you find!

							Thanx, Paul
Willy Tarreau Oct. 7, 2023, 7:06 a.m. UTC | #6 
On Thu, Oct 05, 2023 at 05:01:22PM -0700, Paul E. McKenney wrote:
> On Thu, Oct 05, 2023 at 03:30:52PM -0600, Shuah Khan wrote:
> > On 10/5/23 14:58, Paul E. McKenney wrote:
> > > On Thu, Oct 05, 2023 at 10:28:05PM +0200, Thomas Weißschuh wrote:
> > > > On 2023-10-05 14:15:31-0600, Shuah Khan wrote:
> > > > > Hi Thomas,
> > > > > 
> > > > > On 10/5/23 11:00, Thomas Weißschuh wrote:
> > > > > > Hi Shuah,
> > > > > > 
> > > > > > I'd like to test the current state of nolibc in linux-next.
> > > > > > Could pull the request below into your nolibc branch?
> > > > > > 
> > > > > > I'll do some manual tests this weekend, too.
> > > > > > 
> > > > > > 
> > > > > > Thanks,
> > > > > > Thomas
> > > > > > 
> > > > > > 
> > > > > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > > > > 
> > > > > >     Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > > > > 
> > > > > > are available in the Git repository at:
> > > > > > 
> > > > > >     https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next
> > > > > > 
> > > > > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > > > > 
> > > > > >     tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > > > > 
> > > > > Absolutely. Do you mind tagging and pushing the tag and send
> > > > > pull request with the tag?
> > > > 
> > > > Sure, here it is:
> > > > 
> > > > 
> > > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > > 
> > > >    Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > > 
> > > > are available in the Git repository at:
> > > > 
> > > >    https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc-next.2023.10.05a
> > > > 
> > > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > > 
> > > >    tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > > 
> > > Looks good on my laptop:
> > > 
> > > make run:
> > > 
> > > 	160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> > > 
> > > make run-user:
> > > 
> > > 	160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> > > 
> > > Shuah, I can take nolibc for the upcoming merge window (I believe that
> > > it is my turn to do so), but if you would prefer to take them, that also
> > > works for me.  Either way, just let me know.
> > 
> > Yes it is your turn. Please go ahead and take them.
> 
> Very good, I will merge them in and post them to the relevant email lists.
> 
> > I will pull and do testing and update you on how it went.
> 
> Looking forward to seeing what you find!

In the list I'm seeing this one which is a fix for breakage introduced
in 6.6-rc1:

  commit 3c9b7c4a228bf8cca2f92abb65575cdd54065302 (korg-nolibc/fixes, 20230830-nolibc-fixes)
  Author: Ammar Faizi <ammarfaizi2@gnuweeb.org>
  Date:   Wed Aug 30 08:02:23 2023 +0700

    tools/nolibc: i386: Fix a stack misalign bug on _start
    
    The ABI mandates that the %esp register must be a multiple of 16 when
    executing a 'call' instruction.
  ...

We'll have to send it separately so that it gets into 6.6 soon enough.
And I think the update of the tree location in the MAINTAINERS file
would be deserved as well.

Paul, Shuah, what's the preferred way for you to get fixes for the current
kernel now ? Do you prefer a PR based on a specific branch or just a patch ?

Thanks!
Willy
Paul E. McKenney Oct. 7, 2023, 3:42 p.m. UTC | #7 
On Sat, Oct 07, 2023 at 09:06:30AM +0200, Willy Tarreau wrote:
> On Thu, Oct 05, 2023 at 05:01:22PM -0700, Paul E. McKenney wrote:
> > On Thu, Oct 05, 2023 at 03:30:52PM -0600, Shuah Khan wrote:
> > > On 10/5/23 14:58, Paul E. McKenney wrote:
> > > > On Thu, Oct 05, 2023 at 10:28:05PM +0200, Thomas Weißschuh wrote:
> > > > > On 2023-10-05 14:15:31-0600, Shuah Khan wrote:
> > > > > > Hi Thomas,
> > > > > > 
> > > > > > On 10/5/23 11:00, Thomas Weißschuh wrote:
> > > > > > > Hi Shuah,
> > > > > > > 
> > > > > > > I'd like to test the current state of nolibc in linux-next.
> > > > > > > Could pull the request below into your nolibc branch?
> > > > > > > 
> > > > > > > I'll do some manual tests this weekend, too.
> > > > > > > 
> > > > > > > 
> > > > > > > Thanks,
> > > > > > > Thomas
> > > > > > > 
> > > > > > > 
> > > > > > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > > > > > 
> > > > > > >     Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > > > > > 
> > > > > > > are available in the Git repository at:
> > > > > > > 
> > > > > > >     https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next
> > > > > > > 
> > > > > > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > > > > > 
> > > > > > >     tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > > > > > 
> > > > > > Absolutely. Do you mind tagging and pushing the tag and send
> > > > > > pull request with the tag?
> > > > > 
> > > > > Sure, here it is:
> > > > > 
> > > > > 
> > > > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > > > 
> > > > >    Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > > > 
> > > > > are available in the Git repository at:
> > > > > 
> > > > >    https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc-next.2023.10.05a
> > > > > 
> > > > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > > > 
> > > > >    tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > > > 
> > > > Looks good on my laptop:
> > > > 
> > > > make run:
> > > > 
> > > > 	160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> > > > 
> > > > make run-user:
> > > > 
> > > > 	160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> > > > 
> > > > Shuah, I can take nolibc for the upcoming merge window (I believe that
> > > > it is my turn to do so), but if you would prefer to take them, that also
> > > > works for me.  Either way, just let me know.
> > > 
> > > Yes it is your turn. Please go ahead and take them.
> > 
> > Very good, I will merge them in and post them to the relevant email lists.
> > 
> > > I will pull and do testing and update you on how it went.
> > 
> > Looking forward to seeing what you find!
> 
> In the list I'm seeing this one which is a fix for breakage introduced
> in 6.6-rc1:
> 
>   commit 3c9b7c4a228bf8cca2f92abb65575cdd54065302 (korg-nolibc/fixes, 20230830-nolibc-fixes)
>   Author: Ammar Faizi <ammarfaizi2@gnuweeb.org>
>   Date:   Wed Aug 30 08:02:23 2023 +0700
> 
>     tools/nolibc: i386: Fix a stack misalign bug on _start
>     
>     The ABI mandates that the %esp register must be a multiple of 16 when
>     executing a 'call' instruction.
>   ...
> 
> We'll have to send it separately so that it gets into 6.6 soon enough.
> And I think the update of the tree location in the MAINTAINERS file
> would be deserved as well.
> 
> Paul, Shuah, what's the preferred way for you to get fixes for the current
> kernel now ? Do you prefer a PR based on a specific branch or just a patch ?

The easiest for me would be if you rebased your stack on top of this
new fix, all still based on v6.6-rc1.  I can then pull the new stack,
including fix, test it, and submit the fix to Linus in a few days,
assuming testing goes well.

Would something else work better for you guys?

							Thanx, Paul
Thomas Weißschuh Oct. 8, 2023, 12:58 p.m. UTC | #8 
Hi Paul,

On 2023-10-07 08:42:53-0700, Paul E. McKenney wrote:
> On Sat, Oct 07, 2023 at 09:06:30AM +0200, Willy Tarreau wrote:
> > On Thu, Oct 05, 2023 at 05:01:22PM -0700, Paul E. McKenney wrote:
> > > On Thu, Oct 05, 2023 at 03:30:52PM -0600, Shuah Khan wrote:
> > > > On 10/5/23 14:58, Paul E. McKenney wrote:
> > > > > On Thu, Oct 05, 2023 at 10:28:05PM +0200, Thomas Weißschuh wrote:
> > > > > > On 2023-10-05 14:15:31-0600, Shuah Khan wrote:
> > > > > > > Hi Thomas,
> > > > > > > 
> > > > > > > On 10/5/23 11:00, Thomas Weißschuh wrote:
> > > > > > > > Hi Shuah,
> > > > > > > > 
> > > > > > > > I'd like to test the current state of nolibc in linux-next.
> > > > > > > > Could pull the request below into your nolibc branch?
> > > > > > > > 
> > > > > > > > I'll do some manual tests this weekend, too.
> > > > > > > > 
> > > > > > > > 
> > > > > > > > Thanks,
> > > > > > > > Thomas
> > > > > > > > 
> > > > > > > > 
> > > > > > > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > > > > > > 
> > > > > > > >     Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > > > > > > 
> > > > > > > > are available in the Git repository at:
> > > > > > > > 
> > > > > > > >     https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next
> > > > > > > > 
> > > > > > > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > > > > > > 
> > > > > > > >     tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > > > > > > 
> > > > > > > Absolutely. Do you mind tagging and pushing the tag and send
> > > > > > > pull request with the tag?
> > > > > > 
> > > > > > Sure, here it is:
> > > > > > 
> > > > > > 
> > > > > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > > > > 
> > > > > >    Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > > > > 
> > > > > > are available in the Git repository at:
> > > > > > 
> > > > > >    https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc-next.2023.10.05a
> > > > > > 
> > > > > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > > > > 
> > > > > >    tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > > > > 
> > > > > Looks good on my laptop:
> > > > > 
> > > > > make run:
> > > > > 
> > > > > 	160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> > > > > 
> > > > > make run-user:
> > > > > 
> > > > > 	160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> > > > > 
> > > > > Shuah, I can take nolibc for the upcoming merge window (I believe that
> > > > > it is my turn to do so), but if you would prefer to take them, that also
> > > > > works for me.  Either way, just let me know.
> > > > 
> > > > Yes it is your turn. Please go ahead and take them.
> > > 
> > > Very good, I will merge them in and post them to the relevant email lists.
> > > 
> > > > I will pull and do testing and update you on how it went.
> > > 
> > > Looking forward to seeing what you find!
> > 
> > In the list I'm seeing this one which is a fix for breakage introduced
> > in 6.6-rc1:
> > 
> >   commit 3c9b7c4a228bf8cca2f92abb65575cdd54065302 (korg-nolibc/fixes, 20230830-nolibc-fixes)
> >   Author: Ammar Faizi <ammarfaizi2@gnuweeb.org>
> >   Date:   Wed Aug 30 08:02:23 2023 +0700
> > 
> >     tools/nolibc: i386: Fix a stack misalign bug on _start
> >     
> >     The ABI mandates that the %esp register must be a multiple of 16 when
> >     executing a 'call' instruction.
> >   ...
> > 
> > We'll have to send it separately so that it gets into 6.6 soon enough.
> > And I think the update of the tree location in the MAINTAINERS file
> > would be deserved as well.
> > 
> > Paul, Shuah, what's the preferred way for you to get fixes for the current
> > kernel now ? Do you prefer a PR based on a specific branch or just a patch ?
> 
> The easiest for me would be if you rebased your stack on top of this
> new fix, all still based on v6.6-rc1.  I can then pull the new stack,
> including fix, test it, and submit the fix to Linus in a few days,
> assuming testing goes well.
> 
> Would something else work better for you guys?

With "stack" are you referring to only the fixes that are intended for
v6.6?
It sounds a bit like it should also included patches that are only meant
for v6.7 .

If it is only for the fixes, see below the request.
Note that I dropped the patch
"tools/nolibc: drop test for getauxval(AT_PAGESZ)" as it's not actually
a fix.

The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:

  Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)

are available in the Git repository at:

  https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git fixes

for you to fetch changes up to ac06a8400561f2e4f204e88c130970fb1b9f470c:

  MAINTAINERS: nolibc: update tree location (2023-10-07 12:41:14 +0200)

----------------------------------------------------------------
Ammar Faizi (1):
      tools/nolibc: i386: Fix a stack misalign bug on _start

Thomas Weißschuh (1):
      MAINTAINERS: nolibc: update tree location

 MAINTAINERS                      | 2 +-
 tools/include/nolibc/arch-i386.h | 4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)
Paul E. McKenney Oct. 8, 2023, 4:27 p.m. UTC | #9 
On Sun, Oct 08, 2023 at 02:58:15PM +0200, Thomas Weißschuh wrote:
> Hi Paul,
> 
> On 2023-10-07 08:42:53-0700, Paul E. McKenney wrote:
> > On Sat, Oct 07, 2023 at 09:06:30AM +0200, Willy Tarreau wrote:
> > > On Thu, Oct 05, 2023 at 05:01:22PM -0700, Paul E. McKenney wrote:
> > > > On Thu, Oct 05, 2023 at 03:30:52PM -0600, Shuah Khan wrote:
> > > > > On 10/5/23 14:58, Paul E. McKenney wrote:
> > > > > > On Thu, Oct 05, 2023 at 10:28:05PM +0200, Thomas Weißschuh wrote:
> > > > > > > On 2023-10-05 14:15:31-0600, Shuah Khan wrote:
> > > > > > > > Hi Thomas,
> > > > > > > > 
> > > > > > > > On 10/5/23 11:00, Thomas Weißschuh wrote:
> > > > > > > > > Hi Shuah,
> > > > > > > > > 
> > > > > > > > > I'd like to test the current state of nolibc in linux-next.
> > > > > > > > > Could pull the request below into your nolibc branch?
> > > > > > > > > 
> > > > > > > > > I'll do some manual tests this weekend, too.
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > Thanks,
> > > > > > > > > Thomas
> > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > > > > > > > 
> > > > > > > > >     Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > > > > > > > 
> > > > > > > > > are available in the Git repository at:
> > > > > > > > > 
> > > > > > > > >     https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc/next
> > > > > > > > > 
> > > > > > > > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > > > > > > > 
> > > > > > > > >     tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > > > > > > > 
> > > > > > > > Absolutely. Do you mind tagging and pushing the tag and send
> > > > > > > > pull request with the tag?
> > > > > > > 
> > > > > > > Sure, here it is:
> > > > > > > 
> > > > > > > 
> > > > > > > The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> > > > > > > 
> > > > > > >    Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> > > > > > > 
> > > > > > > are available in the Git repository at:
> > > > > > > 
> > > > > > >    https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git nolibc-next.2023.10.05a
> > > > > > > 
> > > > > > > for you to fetch changes up to ab663cc32912914258bc8a2fbd0e753f552ee9d8:
> > > > > > > 
> > > > > > >    tools/nolibc: automatically detect necessity to use pselect6 (2023-09-28 09:20:35 +0200)
> > > > > > 
> > > > > > Looks good on my laptop:
> > > > > > 
> > > > > > make run:
> > > > > > 
> > > > > > 	160 test(s): 160 passed,   0 skipped,   0 failed => status: success
> > > > > > 
> > > > > > make run-user:
> > > > > > 
> > > > > > 	160 test(s): 158 passed,   2 skipped,   0 failed => status: warning
> > > > > > 
> > > > > > Shuah, I can take nolibc for the upcoming merge window (I believe that
> > > > > > it is my turn to do so), but if you would prefer to take them, that also
> > > > > > works for me.  Either way, just let me know.
> > > > > 
> > > > > Yes it is your turn. Please go ahead and take them.
> > > > 
> > > > Very good, I will merge them in and post them to the relevant email lists.
> > > > 
> > > > > I will pull and do testing and update you on how it went.
> > > > 
> > > > Looking forward to seeing what you find!
> > > 
> > > In the list I'm seeing this one which is a fix for breakage introduced
> > > in 6.6-rc1:
> > > 
> > >   commit 3c9b7c4a228bf8cca2f92abb65575cdd54065302 (korg-nolibc/fixes, 20230830-nolibc-fixes)
> > >   Author: Ammar Faizi <ammarfaizi2@gnuweeb.org>
> > >   Date:   Wed Aug 30 08:02:23 2023 +0700
> > > 
> > >     tools/nolibc: i386: Fix a stack misalign bug on _start
> > >     
> > >     The ABI mandates that the %esp register must be a multiple of 16 when
> > >     executing a 'call' instruction.
> > >   ...
> > > 
> > > We'll have to send it separately so that it gets into 6.6 soon enough.
> > > And I think the update of the tree location in the MAINTAINERS file
> > > would be deserved as well.
> > > 
> > > Paul, Shuah, what's the preferred way for you to get fixes for the current
> > > kernel now ? Do you prefer a PR based on a specific branch or just a patch ?
> > 
> > The easiest for me would be if you rebased your stack on top of this
> > new fix, all still based on v6.6-rc1.  I can then pull the new stack,
> > including fix, test it, and submit the fix to Linus in a few days,
> > assuming testing goes well.
> > 
> > Would something else work better for you guys?
> 
> With "stack" are you referring to only the fixes that are intended for
> v6.6?
> It sounds a bit like it should also included patches that are only meant
> for v6.7 .
> 
> If it is only for the fixes, see below the request.
> Note that I dropped the patch
> "tools/nolibc: drop test for getauxval(AT_PAGESZ)" as it's not actually
> a fix.
> 
> The following changes since commit 0bb80ecc33a8fb5a682236443c1e740d5c917d1d:
> 
>   Linux 6.6-rc1 (2023-09-10 16:28:41 -0700)
> 
> are available in the Git repository at:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/nolibc/linux-nolibc.git fixes
> 
> for you to fetch changes up to ac06a8400561f2e4f204e88c130970fb1b9f470c:
> 
>   MAINTAINERS: nolibc: update tree location (2023-10-07 12:41:14 +0200)
> 
> ----------------------------------------------------------------
> Ammar Faizi (1):
>       tools/nolibc: i386: Fix a stack misalign bug on _start
> 
> Thomas Weißschuh (1):
>       MAINTAINERS: nolibc: update tree location
> 
>  MAINTAINERS                      | 2 +-
>  tools/include/nolibc/arch-i386.h | 4 +++-
>  2 files changed, 4 insertions(+), 2 deletions(-)

I can make it work either way, your choice.

Given a separate nolibc/fixes and nolibc/next branch, as you have now,
what I do is pull them separately.  I test the nolibc/fixes branch
and also the merge with nolibc/next.  Please see the -rcu branch
nolibc-merge.2023.10.08a to see the result.  I send a pull request
to Linus for nolibc/fixes after a few days exposure to -next testing,
and for the merge into the upcoming merge window.

Test results for nolibc/fixes:
"make run": 160 test(s): 160 passed,   0 skipped,   0 failed => status: success
"make run-user": 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning

Test results for the merge of nolibc/fixes and nolibc/next:
"make run": 160 test(s): 160 passed,   0 skipped,   0 failed => status: success
"make run-user": 160 test(s): 158 passed,   2 skipped,   0 failed => status: warning

This approach can work well, but has a couple of potential weaknesses:

1.	Bisectability given that any bugs addressed by the "nolibc/fixes"
	branch are in full force in the "nolibc/next" branch.

2.	Any merge conflicts end up being addressed in the merge commit,
	and I might make the wrong choice for conflict resolution.

3.	There can be duplicate commits, as is currently the case for
	both commits on the "nolibc/fixes" branch.

Nonetheless, if you prefer the merge approach, we absolutely can make
this work.  For one thing, this is how many trees operate today.  But if
we take this approach, can we please base "nolibc/fixes" on top of the
"nolibc-next" commit 4b4a30ea14d1 ("tools/nolibc: i386: Fix a stack
misalign bug on _start")?

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.

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
Willy Tarreau Oct. 9, 2023, 6:53 a.m. UTC | #10 
Hi Paul,

On Sun, Oct 08, 2023 at 09:27:43AM -0700, Paul E. McKenney wrote:
(...)
> The other approach involves rebasing the "nolibc/next" stack
> on top of the "nolibc/fixes" stack.

That was my initial expectation as well, it's much easier, preserves
the patches ordering so it guarantees that all fixes are always present
in -next and that there won't be conflicts when they're finally submitted.

> 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.

Indeed, it also allows to test both together and can reduce the cost of
testing (unless we really want to test something specific to the fixes
branch once in a while).

> 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.

I tend to think that anything called "-next" should mostly be expected
to change over time and support rebases. One good reason for this is to
remerge fixes for recently added changes so as not to needlessly leave
bogus commits in the history, since that tends to break bisect.

> 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.

Good idea, feel free to propose a patch ;-)

Thanks!
Willy
Thomas Weißschuh Oct. 9, 2023, 7:22 a.m. UTC | #11 
Hi Willy, Paul,

On 2023-10-09 08:53:58+0200, Willy Tarreau wrote:
> On Sun, Oct 08, 2023 at 09:27:43AM -0700, Paul E. McKenney wrote:
> (...)
> > The other approach involves rebasing the "nolibc/next" stack
> > on top of the "nolibc/fixes" stack.
> 
> That was my initial expectation as well, it's much easier, preserves
> the patches ordering so it guarantees that all fixes are always present
> in -next and that there won't be conflicts when they're finally submitted.

The workflow Paul described indeed makes a lot of sense.

I can redo it this afternoon.

> [..]

> > 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.
> 
> Good idea, feel free to propose a patch ;-)

How about directly folding it into the original patch?
I can take care of that later today, too.

Thomas
Willy Tarreau Oct. 9, 2023, 7:30 a.m. UTC | #12 
On Mon, Oct 09, 2023 at 09:22:59AM +0200, Thomas Weißschuh wrote:
> Hi Willy, Paul,
> 
> On 2023-10-09 08:53:58+0200, Willy Tarreau wrote:
> > On Sun, Oct 08, 2023 at 09:27:43AM -0700, Paul E. McKenney wrote:
> > (...)
> > > The other approach involves rebasing the "nolibc/next" stack
> > > on top of the "nolibc/fixes" stack.
> > 
> > That was my initial expectation as well, it's much easier, preserves
> > the patches ordering so it guarantees that all fixes are always present
> > in -next and that there won't be conflicts when they're finally submitted.
> 
> The workflow Paul described indeed makes a lot of sense.
> 
> I can redo it this afternoon.
> 
> > [..]
> 
> > > 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.
> > 
> > Good idea, feel free to propose a patch ;-)
> 
> How about directly folding it into the original patch?
> I can take care of that later today, too.

OK thank you very much Thomas!
Willy
Thomas Weißschuh Oct. 9, 2023, 11:25 a.m. UTC | #13 
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
Willy Tarreau Oct. 9, 2023, 12:02 p.m. UTC | #14 
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.
> 
> 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.

Nice work, thanks very much Thomas!
Willy
Paul E. McKenney Oct. 9, 2023, 1:54 p.m. UTC | #15 
On Mon, Oct 09, 2023 at 09:22:59AM +0200, Thomas Weißschuh wrote:
> Hi Willy, Paul,
> 
> On 2023-10-09 08:53:58+0200, Willy Tarreau wrote:
> > On Sun, Oct 08, 2023 at 09:27:43AM -0700, Paul E. McKenney wrote:
> > (...)
> > > The other approach involves rebasing the "nolibc/next" stack
> > > on top of the "nolibc/fixes" stack.
> > 
> > That was my initial expectation as well, it's much easier, preserves
> > the patches ordering so it guarantees that all fixes are always present
> > in -next and that there won't be conflicts when they're finally submitted.
> 
> The workflow Paul described indeed makes a lot of sense.
> 
> I can redo it this afternoon.
> 
> > [..]
> 
> > > 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.
> > 
> > Good idea, feel free to propose a patch ;-)
> 
> How about directly folding it into the original patch?
> I can take care of that later today, too.

Works for me, and thank you!

							Thanx, Paul
Paul E. McKenney Oct. 9, 2023, 4:18 p.m. UTC | #16 
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