From: Sven Schnelle <svens@linux.ibm.com>
To: Willy Tarreau <w@1wt.eu>
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/5] nolibc: add support for s390
Date: Sat, 10 Dec 2022 10:34:08 +0100 [thread overview]
Message-ID: <yt9dmt7vtxf3.fsf@linux.ibm.com> (raw)
In-Reply-To: <20221210090728.GB21743@1wt.eu> (Willy Tarreau's message of "Sat, 10 Dec 2022 10:07:28 +0100")
Willy Tarreau <w@1wt.eu> writes:
> On Fri, Dec 09, 2022 at 03:19:36PM +0100, Sven Schnelle wrote:
>> Use arch-x86_64 as a template. Not really different, but
>> we have our own mmap syscall which takes a structure instead
>> of discrete arguments.
>
> I'm fine with placing the mmap syscall inside the arch-s390 file, though
> it differs from what's done for other syscalls. But I admit that mmap is
> one of these syscalls that differ between various archs and that it's not
> shocking to leave it per-arch.
>
> However you're having an issue here:
>
>> diff --git a/tools/include/nolibc/arch-s390.h b/tools/include/nolibc/arch-s390.h
>> new file mode 100644
>> index 000000000000..34b744e2f7d6
>> --- /dev/null
>> +++ b/tools/include/nolibc/arch-s390.h
> ^^^^^^^^^
> vs:
>
>> diff --git a/tools/include/nolibc/arch.h b/tools/include/nolibc/arch.h
>> index 4c6992321b0d..fcded65b98d7 100644
>> --- a/tools/include/nolibc/arch.h
>> +++ b/tools/include/nolibc/arch.h
>> @@ -27,6 +27,8 @@
>> #include "arch-mips.h"
>> #elif defined(__riscv)
>> #include "arch-riscv.h"
>> +#elif defined(__s390x__)
>> +#include "arch-s390x.h"
> ^^^^^^^^^^
>
> As you see the file is not the same so if you build by including nolibc.h
> directly it will not work. The difference between s390 and s390x has never
> been very clear to me, so I can't easily suggest which name is the most
> suitable, but you'll definitely have to choose one :-) If it's just a
> matter of dropping that trailing 'x' there, I think we can fix your patch
> here without re-submitting, let us know.
Whoops. One of my colleagues suggested that i should name the file
arch-390x.h. Reason for this is that the architecture name "s390"
describes the 31bit (compat) architecture mode in userspace, and "s390x"
the 64 bit mode. To make it a bit more complicated, the architecture in
the kernel is named "s390". That's because in the beginning the kernel
could run in 31bit or 64 bit mode, and there can be only one
architecture name. When support for running 31bit kernels was removed
years ago, the architecture name s390 was kept because renaming the
architecture would have been quite some fun. So in short:
Kernel s390 == 64 bit only
Userspace s390 == 31 bit
Userspace s390x == 64 bit
So i tried renaming the header file, noted that the Makefile just uses:
nolibc_arch := $(patsubst arm64,aarch64,$(ARCH))
arch_file := arch-$(nolibc_arch).h
which would then need special handling. Obviously i failed to revert the
change completely during rebase.
So it should be:
>> +#elif defined(__s390x__)
>> +#include "arch-s390.h"
I'm fine with both - either you fixing it up or me sending a v2.
Thanks!
Sven
next prev parent reply other threads:[~2022-12-10 9:34 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 14:19 [PATCH 0/5] add s390 support to nolibc and rcutorture Sven Schnelle
2022-12-09 14:19 ` [PATCH 1/5] nolibc: fix fd_set type Sven Schnelle
2022-12-10 8:46 ` Willy Tarreau
2022-12-09 14:19 ` [PATCH 2/5] nolibc: add support for s390 Sven Schnelle
2022-12-10 9:07 ` Willy Tarreau
2022-12-10 9:34 ` Sven Schnelle [this message]
2022-12-10 9:37 ` Willy Tarreau
2022-12-10 9:39 ` Sven Schnelle
2022-12-10 9:44 ` Willy Tarreau
2022-12-10 17:57 ` Paul E. McKenney
2022-12-10 22:05 ` Willy Tarreau
2022-12-11 5:51 ` Paul E. McKenney
2022-12-27 21:35 ` Willy Tarreau
2023-01-02 8:17 ` Sven Schnelle
2023-01-02 8:41 ` Willy Tarreau
2023-01-02 9:33 ` Sven Schnelle
2023-01-02 9:50 ` Willy Tarreau
2022-12-09 14:19 ` [PATCH 3/5] selftests/nolibc: add s390 support Sven Schnelle
2022-12-10 9:08 ` Willy Tarreau
2022-12-09 14:19 ` [PATCH 4/5] rcutorture: add support for s390 Sven Schnelle
2022-12-09 14:19 ` [PATCH 5/5] rcutorture: build initrd for rcutorture with nolibc Sven Schnelle
2022-12-09 15:03 ` [PATCH 0/5] add s390 support to nolibc and rcutorture Paul E. McKenney
2022-12-09 15:28 ` Willy Tarreau
2022-12-10 1:26 ` Paul E. McKenney
2022-12-10 9:12 ` 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=yt9dmt7vtxf3.fsf@linux.ibm.com \
--to=svens@linux.ibm.com \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@kernel.org \
--cc=rostedt@goodmis.org \
--cc=w@1wt.eu \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox