Message ID | 11a790c0-f9c0-49eb-b14f-56b962af6d2d@t-8ch.de |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:612c:2016:b0:403:3b70:6f57 with SMTP id fe22csp445355vqb; Thu, 5 Oct 2023 10:13:00 -0700 (PDT) X-Google-Smtp-Source: AGHT+IFKqo/VS01kifItSGEgIClaUiNhqB9cfu6lws7F0lVSB8W8pdJYMDYYAvi7wUJSTCuJ0Gdf X-Received: by 2002:a05:6808:4349:b0:3ad:f8a7:1485 with SMTP id dx9-20020a056808434900b003adf8a71485mr4984919oib.18.1696525979970; Thu, 05 Oct 2023 10:12:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1696525979; cv=none; d=google.com; s=arc-20160816; b=MuthQG045Mp6M1Xq4XNzfR0pXUpYpIYaKF6rDzo3IJOPwXS6VyQWOeF7eRj/CXsS6K 2UwHGyADZtWye8oanOuLYA02C910NPJlJrDefqLBA0uGf4diSkBSGscXCRoAFj1c00Wr LWjPKB4eQS9LWwxZieXI51hPhWTqERDsDGCMLimVh6aw4ZTD7jNIJkFB2KUrpTIOPbxX IG/kFLy+IMC4MK3lLRNWHq+vEbnjDXVLg7kmwFzv3Yzejsb6ckdvJUy06CYhMXpliuCR m6oXtbBCX27yL9j4UOuX1Vg8J2yoJJHzxFQf4QdxMc+0EROTxilsr/HnP8kiwk/pgVAV 8Akw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-disposition :mime-version:message-id:subject:cc:to:from:date:dkim-signature; bh=DX1T+F7elivTG2YaRDYfgjKPomsEt/+xbp0mEnep/Gw=; fh=Y+2PXxp6RwvycGpPjMRd9F3L5OPuQnq0P/QzEL3LYKU=; b=pnmfCfBER2HEYnZSAabYc70IFo+dNQsUpvs3cHFzVjvDtSsdmLJ4+fntBuEltbC7tZ M1WRgCIxTW7Hg2bINXJH2CaBMkAVoHJ5kOEkUs0rcMkBISgwWvmVcVXxc1T2igF62Szz 9pMGaqNnzVjghMczLNdRLLgV/So009T3jVxgop/4/d/ceGQyreRPzadSnGnHxPz11/qS y/kFMZETixQIptbbxOvxmFaoOgXlDgwnpb8lES0m+QceGe+NHJA/Cm81fvfe2U7v0yNd VzrpNuUjQrl6brUkWaH6eA+V6KrQNv7843fJA0VNoOjgTqaBVTlshqyvF57G77iN/p54 HA4Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=D5TggrKa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from snail.vger.email (snail.vger.email. [2620:137:e000::3:7]) by mx.google.com with ESMTPS id t10-20020a65608a000000b00578b6e32b5dsi1778057pgu.405.2023.10.05.10.12.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 05 Oct 2023 10:12:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7; Authentication-Results: mx.google.com; dkim=pass header.i=@weissschuh.net header.s=mail header.b=D5TggrKa; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (depot.vger.email [IPv6:2620:137:e000::3:0]) by snail.vger.email (Postfix) with ESMTP id 4A7C6833816A; Thu, 5 Oct 2023 10:12:59 -0700 (PDT) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.10 at snail.vger.email Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230118AbjJERMr (ORCPT <rfc822;ezelljr.billy@gmail.com> + 18 others); Thu, 5 Oct 2023 13:12:47 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39284 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230174AbjJERMK (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Thu, 5 Oct 2023 13:12:10 -0400 Received: from todd.t-8ch.de (todd.t-8ch.de [159.69.126.157]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B83C661A3 for <linux-kernel@vger.kernel.org>; Thu, 5 Oct 2023 10:00:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=weissschuh.net; s=mail; t=1696525241; bh=XJfHEXVj41opqthiiRW86PzlGVbMQ3PRnc0rzAP6Idk=; h=Date:From:To:Cc:Subject:From; b=D5TggrKaMcAdNTcxx5F0SX/IQZAbd3gtg8eGPFlTYef5oir06Yi7RDY8aUuRl89A/ xF/+jFsoYqUmLex542nXQga1tdsPlcKk+U4ttiPo2IiQb7KUWgPw/VDqQducL9IK5H rw0iCc3bnAuTRaADwAbCZmAtErpVa2PKoH8kk3NY= Date: Thu, 5 Oct 2023 19:00:40 +0200 From: Thomas =?utf-8?q?Wei=C3=9Fschuh?= <linux@weissschuh.net> To: Shuah Khan <shuah@kernel.org> Cc: Willy Tarreau <w@1wt.eu>, linux-kernel@vger.kernel.org Subject: nolibc changes since 6.6-rc1 for linux-next Message-ID: <11a790c0-f9c0-49eb-b14f-56b962af6d2d@t-8ch.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_BLOCKED, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.4 (snail.vger.email [0.0.0.0]); Thu, 05 Oct 2023 10:12:59 -0700 (PDT) X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1778936425935514671 X-GMAIL-MSGID: 1778936425935514671 |
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/nextMessage
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
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
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
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
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
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
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
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
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(-)
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
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
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
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
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
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
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
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