From: Willy Tarreau <w@1wt.eu>
To: Zhangjin Wu <falcon@tinylab.org>
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org,
thomas@t-8ch.de
Subject: Re: [PATCH v3 0/3] nolibc: add part2 of support for rv32
Date: Tue, 6 Jun 2023 08:45:32 +0200 [thread overview]
Message-ID: <ZH7WDDgACvzVzV6e@1wt.eu> (raw)
In-Reply-To: <20230606063421.355411-1-falcon@tinylab.org>
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
WARNING: multiple messages have this Message-ID (diff)
From: Willy Tarreau <w@1wt.eu>
To: Zhangjin Wu <falcon@tinylab.org>
Cc: arnd@arndb.de, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-riscv@lists.infradead.org,
thomas@t-8ch.de
Subject: Re: [PATCH v3 0/3] nolibc: add part2 of support for rv32
Date: Tue, 6 Jun 2023 08:45:32 +0200 [thread overview]
Message-ID: <ZH7WDDgACvzVzV6e@1wt.eu> (raw)
In-Reply-To: <20230606063421.355411-1-falcon@tinylab.org>
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
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
next prev parent reply other threads:[~2023-06-06 6:45 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-03 9:00 [PATCH v3 0/3] nolibc: add part2 of support for rv32 Zhangjin Wu
2023-06-03 9:00 ` Zhangjin Wu
2023-06-03 9:01 ` [PATCH v3 1/3] tools/nolibc: fix up #error compile failures with -ENOSYS Zhangjin Wu
2023-06-03 9:01 ` Zhangjin Wu
2023-06-06 7:35 ` Arnd Bergmann
2023-06-06 7:35 ` Arnd Bergmann
2023-06-07 5:19 ` Zhangjin Wu
2023-06-07 5:19 ` Zhangjin Wu
2023-06-07 8:45 ` Arnd Bergmann
2023-06-07 8:45 ` Arnd Bergmann
2023-06-07 9:46 ` Zhangjin Wu
2023-06-07 9:46 ` Zhangjin Wu
2023-06-07 10:02 ` Arnd Bergmann
2023-06-07 10:02 ` Arnd Bergmann
2023-06-07 13:26 ` Zhangjin Wu
2023-06-07 13:26 ` Zhangjin Wu
2023-06-03 9:04 ` [PATCH v3 2/3] tools/nolibc: fix up undeclared syscall macros with #ifdef and -ENOSYS Zhangjin Wu
2023-06-03 9:04 ` Zhangjin Wu
2023-06-03 9:05 ` [PATCH v3 3/3] selftests/nolibc: riscv: customize makefile for rv32 Zhangjin Wu
2023-06-03 9:05 ` Zhangjin Wu
2023-06-06 7:43 ` Arnd Bergmann
2023-06-06 7:43 ` Arnd Bergmann
2023-06-06 11:12 ` Zhangjin Wu
2023-06-06 11:12 ` Zhangjin Wu
2023-06-06 11:21 ` Arnd Bergmann
2023-06-06 11:21 ` Arnd Bergmann
2023-06-06 12:07 ` Zhangjin Wu
2023-06-06 12:07 ` Zhangjin Wu
2023-06-07 1:20 ` Zhangjin Wu
2023-06-07 1:20 ` Zhangjin Wu
2023-06-07 4:17 ` Willy Tarreau
2023-06-07 4:17 ` Willy Tarreau
2023-06-07 6:33 ` Zhangjin Wu
2023-06-07 6:33 ` Zhangjin Wu
2023-06-07 7:33 ` Willy Tarreau
2023-06-07 7:33 ` Willy Tarreau
2023-06-07 8:11 ` Zhangjin Wu
2023-06-07 8:11 ` Zhangjin Wu
2023-06-07 10:44 ` Willy Tarreau
2023-06-07 10:44 ` Willy Tarreau
2023-06-06 4:25 ` [PATCH v3 0/3] nolibc: add part2 of support " Zhangjin Wu
2023-06-06 4:25 ` Zhangjin Wu
2023-06-06 4:42 ` Willy Tarreau
2023-06-06 4:42 ` Willy Tarreau
2023-06-06 6:34 ` Zhangjin Wu
2023-06-06 6:34 ` Zhangjin Wu
2023-06-06 6:45 ` Willy Tarreau [this message]
2023-06-06 6:45 ` Willy Tarreau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZH7WDDgACvzVzV6e@1wt.eu \
--to=w@1wt.eu \
--cc=arnd@arndb.de \
--cc=falcon@tinylab.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=thomas@t-8ch.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.