From: Arnd Bergmann <arnd@arndb.de>
To: musl@lists.openwall.com
Subject: Re: [musl] riscv32 v2
Date: Tue, 8 Sep 2020 00:30:27 +0200 [thread overview]
Message-ID: <CAK8P3a1J9QrqFvFagr4aaXTK2ma_6vaRFMR9GCUgY-wHtHcP3w@mail.gmail.com> (raw)
In-Reply-To: <20200907221151.GP3265@brightrain.aerifal.cx>
On Tue, Sep 8, 2020 at 12:12 AM Rich Felker <dalias@libc.org> wrote:
> As an aside, I should probably cleanup the current definition
> framework where IPC_64==0x100 is the default and archs that want 0
> have to define it explicitly. It looks like, for the most part, IPC_64
> is needed iff SYS_ipc is defined.
Right, there are no architectures that provide sys_ipc and want the
flag to be zero.
> Of the archs we support, arm
> (32-bit) and mips{n32,64} seem to be the only ones that lack SYS_ipc
> but need the IPC_64 bit set. Does this agree with your assessment?
I think microblaze is in the same group. Note that for odd reasons it
has always defined the __NR_ipc macro to 117 but hooked it up
to -ENOSYS instead of sys_ipc in the kernel. I'm never quite sure
whether we should treat that as a bug in the header file that we want
to fix, or whether we should keep such constants around in new
headers that were present in older ones.
Arnd
next prev parent reply other threads:[~2020-09-07 22:31 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-04 5:48 Stefan O'Rear
2020-09-07 10:47 ` Stefan O'Rear
2020-09-07 18:06 ` Rich Felker
2020-09-07 21:35 ` Arnd Bergmann
2020-09-07 21:45 ` Rich Felker
2020-09-07 21:58 ` Arnd Bergmann
2020-09-07 22:11 ` Rich Felker
2020-09-07 22:30 ` Arnd Bergmann [this message]
2020-09-08 1:02 ` Rich Felker
2020-09-08 7:00 ` Arnd Bergmann
2020-09-07 11:27 ` Stefan O'Rear
2020-09-07 18:09 ` Rich Felker
2020-09-08 1:54 ` Rich Felker
2020-09-09 6:07 ` Rich Felker
2020-09-09 20:28 ` Rich Felker
2020-09-09 21:28 ` Palmer Dabbelt
2020-09-09 21:36 ` Rich Felker
2020-09-09 23:08 ` Palmer Dabbelt
2020-09-10 7:36 ` Arnd Bergmann
2020-09-10 10:01 ` Vincenzo Frascino
2020-09-11 0:08 ` Palmer Dabbelt
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=CAK8P3a1J9QrqFvFagr4aaXTK2ma_6vaRFMR9GCUgY-wHtHcP3w@mail.gmail.com \
--to=arnd@arndb.de \
--cc=musl@lists.openwall.com \
/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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).