Message ID | cover.1685780412.git.falcon@tinylab.org |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:994d:0:b0:3d9:f83d:47d9 with SMTP id k13csp1547849vqr; Sat, 3 Jun 2023 02:08:55 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7G4RAWVx4bXVVfeed+9t3Iib/Ha46BzF7McNiLY3j8jrGgomP5vTmuqSWiOfez5a8+I4gQ X-Received: by 2002:a05:6808:5c1:b0:399:b7bd:903c with SMTP id d1-20020a05680805c100b00399b7bd903cmr2746583oij.40.1685783335581; Sat, 03 Jun 2023 02:08:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1685783335; cv=none; d=google.com; s=arc-20160816; b=wwdXM+n9YLebdK8pa+IJf5TIP5VykjGRgADaRGd9C8AFqWQtC70lHGBoh8AKBYp9ei +y3RVuFKKrPksldbTR8YWgEsZ1uKLsyqwN+RSnh60zvBpcJZ+l/v4XnRy48bFEGmaOEh Av5BPvkDnT9vhAGfASuVwZ0znGpYPVGCoaBMTCeZbAS6UiTnnDiEPMsAYyiQFqdvr0dz tvE97OqPBumV9fy1/6m+Y2ImnIBE+Fb6gfJbimw7LsYc9/vwMVW7O6r27MGgH5TtAv01 ZSwzJLNAUjZ8sgYTp6svQBMBLAXS93/dRySNcpFUlwV/NYOlwrWdwC1gq2A7rXESRvPz 3lpg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:feedback-id:content-transfer-encoding :mime-version:message-id:date:subject:cc:to:from; bh=vCeNPhiHe5FX/SwCHh4u7xu19HzW+eSbL2jef+4u/EQ=; b=DPpe0j8iDpGrjUPURyK+r2smufnfBszamHahhObJO6oMa5/af2TzPhGMwJ6SwtKw2Z Z7Z95YmbKt5jBSNU61dPJolMrBewqy6jh++yBcGIJ4RzmTRbxRGuas1d7WTpIxZn2utG rq2hD6lcg0YdVPxkbAkMflACugQJBXEzxepFgPxXbgNVfrWxxJcD626vd54vomgDbJUx K3CA8Jp6aFJipXXHPv8j1rfKbY1+hloOVlKC7fVh7NwLhy9FintV96lH8LA/Os/f0EpO Li9s/pqzMRDUnqNRwit6bPwNIWGAY2v2d7Tvz/+5NsZB/+s6LDzK4Y5kuTo1IyOgNZMV glHg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j15-20020a170903024f00b001aaf91ae3acsi2268266plh.485.2023.06.03.02.08.43; Sat, 03 Jun 2023 02:08:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229774AbjFCJBI (ORCPT <rfc822;limurcpp@gmail.com> + 99 others); Sat, 3 Jun 2023 05:01:08 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229550AbjFCJBG (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sat, 3 Jun 2023 05:01:06 -0400 Received: from bg4.exmail.qq.com (bg4.exmail.qq.com [43.154.54.12]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C65D41B5; Sat, 3 Jun 2023 02:01:02 -0700 (PDT) X-QQ-mid: bizesmtp81t1685782850txqcbj5y Received: from linux-lab-host.localdomain ( [119.123.130.226]) by bizesmtp.qq.com (ESMTP) with id ; Sat, 03 Jun 2023 17:00:49 +0800 (CST) X-QQ-SSF: 01200000000000D0V000000A0000000 X-QQ-FEAT: dS+JUNSIibdBnc+tIJt+WeMytSH2tNEkxCjMCD4VPtHgoFNxQaIPNyyj3VrsU L4aLi7UZjLKSyXCsxEAGLpykcZ6lpcX6vh29qsvV3MwdwXcysQei3DXLoqvZ+mmyI684xYV O+/wRohKUsF5llCCmjFXzT9kBRTpbSwE1lTy+dEL+VK+pelCK942/a+1IQRs3HuKn1WVhrM iLVKUx7SJjng4ljrg2pEE5nnEX/ep0Rf1Uj55k3Vbd8T6hlaTlXLxnCX3nWZMu3gLWqn1gI 4I7kD4JLMmWN7SNnGdqjup9qSn1ctiNC0mlpSYUp4EthY61wFhAwe+/rH8Jsx3uQ3yf4pUb fl6OniGg++MT3GHMVagj8FpoPyXXK+Z+l1yKfSlg0y0+KtwVTOPP8PCdFNQrFhUS/qOt+EM X-QQ-GoodBg: 0 X-BIZMAIL-ID: 15397238080264048337 From: Zhangjin Wu <falcon@tinylab.org> To: w@1wt.eu Cc: falcon@tinylab.org, arnd@arndb.de, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org, thomas@t-8ch.de Subject: [PATCH v3 0/3] nolibc: add part2 of support for rv32 Date: Sat, 3 Jun 2023 17:00:36 +0800 Message-Id: <cover.1685780412.git.falcon@tinylab.org> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-QQ-SENDSIZE: 520 Feedback-ID: bizesmtp:tinylab.org:qybglogicsvrsz:qybglogicsvrsz3a-3 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE 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-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1767671947010846519?= X-GMAIL-MSGID: =?utf-8?q?1767671947010846519?= |
Series | nolibc: add part2 of support for rv32 | |
Message
Zhangjin Wu
June 3, 2023, 9 a.m. UTC
Hi, Willy This is the v3 part2 of support for rv32, differs from the v2 part2 [1], we only fix up compile issues in this patchset. With the v3 generic part1 [2] and this patchset, we can compile nolibc for rv32 now. This is based on the idea of suggestions from Arnd [3], instead of '#error' on the unsupported syscall on a target platform, a 'return -ENOSYS' allow us to compile it at first and then allow we fix up the test failures reported by nolibc-test one by one. The first two patches fix up all of the compile failures with '-ENOSYS' (and '#ifdef' if required): tools/nolibc: fix up #error compile failures with -ENOSYS tools/nolibc: fix up undeclared syscall macros with #ifdef and -ENOSYS The last one enables rv32 compile support: selftests/nolibc: riscv: customize makefile for rv32 The above compile support patch here is only for test currently, as Thomas suggested, for a full rv32 support, it should wait for the left parts. Welcome your feedbacks, will wait for enough discussion on this patchset and then send the left parts one by one to fix up the test failures about waitid, llseek and time64 syscalls: ppoll_time64, clock_gettime64, pselect6_time64. So, I do recommend to apply this patchset, it allows us to send the left parts independently, otherwise, all of them should be sent out for review together. with this patchset, the rv32 users may be able to use nolibc although some syscalls still missing :-) Or at least we apply the first two, so, I can manually cherry-pick the compile support patch to do my local test, and the other platform developer may also benefit from them. I'm cleaning up the left parts, but still require some time, I plan to split them to such parts: * part3: waitid, prepared, will send out later * part4: llseek, prepared, will send out later * part5: time64 syscalls, ppoll_time64 ok, will finish them next week (It is a little hard to split them) Best regards, Zhangjin --- [1]: https://lore.kernel.org/linux-riscv/cover.1685387484.git.falcon@tinylab.org/T/#t [2]: https://lore.kernel.org/linux-riscv/cover.1685777982.git.falcon@tinylab.org/T/#t [3]: https://lore.kernel.org/linux-riscv/5e7d2adf-e96f-41ca-a4c6-5c87a25d4c9c@app.fastmail.com/ Zhangjin Wu (3): tools/nolibc: fix up #error compile failures with -ENOSYS tools/nolibc: fix up undeclared syscall macros with #ifdef and -ENOSYS selftests/nolibc: riscv: customize makefile for rv32 tools/include/nolibc/sys.h | 38 ++++++++++++++++--------- tools/testing/selftests/nolibc/Makefile | 11 +++++-- 2 files changed, 34 insertions(+), 15 deletions(-)
Comments
Hi, Arnd Because this patchset is a 'big' change derived from the idea of suggestion from you [3], I do very welcome your feedback about this change, just like Thomas suggested, this requires more discussion before Willy plan to determine merge it or not. The first two convert all compile failures to a return of -ENOSYS, if you do like it, welcome your Reviewed-by. These two are required by the coming new time64 syscalls for rv32, because they depends on how we cope with the unsupported syscalls, returning -ENOSYS is really better than simply fail the compiling. Hi, Thomas, If you are happy with them, welcome your Reviewed-by too, thanks. If the first two are ok, then, I can focus on preparing the left time64 patchsets. The third one is not that urgent, because some important syscalls are still missing for rv32. It is added here only for compile test. Thanks, Zhangjin > Hi, Willy > > This is the v3 part2 of support for rv32, differs from the v2 part2 [1], > we only fix up compile issues in this patchset. > > With the v3 generic part1 [2] and this patchset, we can compile nolibc > for rv32 now. > > This is based on the idea of suggestions from Arnd [3], instead of > '#error' on the unsupported syscall on a target platform, a 'return > -ENOSYS' allow us to compile it at first and then allow we fix up the > test failures reported by nolibc-test one by one. > > The first two patches fix up all of the compile failures with '-ENOSYS' > (and '#ifdef' if required): > > tools/nolibc: fix up #error compile failures with -ENOSYS > tools/nolibc: fix up undeclared syscall macros with #ifdef and -ENOSYS > > The last one enables rv32 compile support: > > selftests/nolibc: riscv: customize makefile for rv32 > > The above compile support patch here is only for test currently, as > Thomas suggested, for a full rv32 support, it should wait for the left > parts. > > Welcome your feedbacks, will wait for enough discussion on this patchset > and then send the left parts one by one to fix up the test failures > about waitid, llseek and time64 syscalls: ppoll_time64, clock_gettime64, > pselect6_time64. > > So, I do recommend to apply this patchset, it allows us to send the left > parts independently, otherwise, all of them should be sent out for > review together. with this patchset, the rv32 users may be able to use > nolibc although some syscalls still missing :-) > > Or at least we apply the first two, so, I can manually cherry-pick the > compile support patch to do my local test, and the other platform > developer may also benefit from them. > > I'm cleaning up the left parts, but still require some time, I plan to > split them to such parts: > > * part3: waitid, prepared, will send out later > * part4: llseek, prepared, will send out later > * part5: time64 syscalls, ppoll_time64 ok, will finish them next week > (It is a little hard to split them) > > Best regards, > Zhangjin > --- > > [1]: https://lore.kernel.org/linux-riscv/cover.1685387484.git.falcon@tinylab.org/T/#t > [2]: https://lore.kernel.org/linux-riscv/cover.1685777982.git.falcon@tinylab.org/T/#t > [3]: https://lore.kernel.org/linux-riscv/5e7d2adf-e96f-41ca-a4c6-5c87a25d4c9c@app.fastmail.com/ > > Zhangjin Wu (3): > tools/nolibc: fix up #error compile failures with -ENOSYS > tools/nolibc: fix up undeclared syscall macros with #ifdef and -ENOSYS > selftests/nolibc: riscv: customize makefile for rv32 > > tools/include/nolibc/sys.h | 38 ++++++++++++++++--------- > tools/testing/selftests/nolibc/Makefile | 11 +++++-- > 2 files changed, 34 insertions(+), 15 deletions(-)
Hi Zhangjin, On Tue, Jun 06, 2023 at 12:25:35PM +0800, Zhangjin Wu wrote: > The first two convert all compile failures to a return of -ENOSYS, if you do > like it, welcome your Reviewed-by. These two are required by the coming new > time64 syscalls for rv32, because they depends on how we cope with the > unsupported syscalls, returning -ENOSYS is really better than simply fail the > compiling. I had a look now and I can sya that I like this. Initially the supported syscalls were so restricted that it was not even imaginable to accept to build without any of them, but now that we're completing the list, some of them are less critical and I don't see why we'd fail to build just because one is missing. So yeah, a big +1 for -ENOSYS. > The third one is not that urgent, because some important syscalls are > still missing for rv32. It is added here only for compile test. I personally have no opinion on this one. I can't judge whether it will make things easier or more complicated at this point. It seems to me that for now it's just avoiding one extra line at the expense of some $(if) on several lines. Maybe it could help add more such archs, or maybe it can make them more complicated to debug, I don't know. I'm interested in others' opinions as well. Thanks, Willy
Willy, Thomas, Arnd > Hi Zhangjin, > > On Tue, Jun 06, 2023 at 12:25:35PM +0800, Zhangjin Wu wrote: > > The first two convert all compile failures to a return of -ENOSYS, if you do > > like it, welcome your Reviewed-by. These two are required by the coming new > > time64 syscalls for rv32, because they depends on how we cope with the > > unsupported syscalls, returning -ENOSYS is really better than simply fail the > > compiling. > > I had a look now and I can sya that I like this. Initially the supported > syscalls were so restricted that it was not even imaginable to accept to > build without any of them, but now that we're completing the list, some > of them are less critical and I don't see why we'd fail to build just > because one is missing. So yeah, a big +1 for -ENOSYS. > Cool, I will prepare the new patchsets on them, welcome your new branch with both of them, of course, still weclome Reviewed-by from Arnd and Thomas. > > The third one is not that urgent, because some important syscalls are > > still missing for rv32. It is added here only for compile test. > > I personally have no opinion on this one. I can't judge whether it will > make things easier or more complicated at this point. It seems to me > that for now it's just avoiding one extra line at the expense of some > $(if) on several lines. Maybe it could help add more such archs, or > maybe it can make them more complicated to debug, I don't know. I'm > interested in others' opinions as well. As I explained why we did it in current way in this reply [1], Thomas had no more questions on it, so I think Thomas was happy with it now and I got his only left suggestion is that may be this patch should be applied after the missing 64bit syscalls being added for there are several important test failures currently, for me, it is ok before or after. Thomas, welcome your Reviewed-by on the makefile patch itself If you are really happy with it now, thanks very much ;-) Willy, I will send the v2 syscalls helpers (also required by the coming 64bit syscalls) and some other patches (mainly for test with faster kernel build) about selftests/nolibc later, because we have not enough time for v6.5 test, so, I suggest we can create new branch for v6.6 and my new patchsets will be for v6.6. Best regards, Zhangjin --- [1]: https://lore.kernel.org/linux-riscv/20230526092029.149351-1-falcon@tinylab.org/ > > Thanks, > Willy
On Tue, Jun 06, 2023 at 02:34:21PM +0800, Zhangjin Wu wrote: > Willy, Thomas, Arnd > > > Hi Zhangjin, > > > > On Tue, Jun 06, 2023 at 12:25:35PM +0800, Zhangjin Wu wrote: > > > The first two convert all compile failures to a return of -ENOSYS, if you do > > > like it, welcome your Reviewed-by. These two are required by the coming new > > > time64 syscalls for rv32, because they depends on how we cope with the > > > unsupported syscalls, returning -ENOSYS is really better than simply fail the > > > compiling. > > > > I had a look now and I can sya that I like this. Initially the supported > > syscalls were so restricted that it was not even imaginable to accept to > > build without any of them, but now that we're completing the list, some > > of them are less critical and I don't see why we'd fail to build just > > because one is missing. So yeah, a big +1 for -ENOSYS. > > > > Cool, I will prepare the new patchsets on them, welcome your new branch > with both of them, of course, still weclome Reviewed-by from Arnd and Thomas. I don't even think a new branch is needed, I can take them as-is it seems. > > > The third one is not that urgent, because some important syscalls are > > > still missing for rv32. It is added here only for compile test. > > > > I personally have no opinion on this one. I can't judge whether it will > > make things easier or more complicated at this point. It seems to me > > that for now it's just avoiding one extra line at the expense of some > > $(if) on several lines. Maybe it could help add more such archs, or > > maybe it can make them more complicated to debug, I don't know. I'm > > interested in others' opinions as well. > > As I explained why we did it in current way in this reply [1], Thomas had no > more questions on it, so I think Thomas was happy with it now and I got his > only left suggestion is that may be this patch should be applied after the > missing 64bit syscalls being added for there are several important test > failures currently, for me, it is ok before or after. > > Thomas, welcome your Reviewed-by on the makefile patch itself If you are really > happy with it now, thanks very much ;-) > > Willy, I will send the v2 syscalls helpers (also required by the coming 64bit > syscalls) and some other patches (mainly for test with faster kernel build) > about selftests/nolibc later, because we have not enough time for v6.5 test, > so, I suggest we can create new branch for v6.6 and my new patchsets will be > for v6.6. Agreed, thank you! Willy