[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK8P3a1J9QrqFvFagr4aaXTK2ma_6vaRFMR9GCUgY-wHtHcP3w@mail.gmail.com>
Date: Tue, 8 Sep 2020 00:30:27 +0200
From: Arnd Bergmann <arnd@...db.de>
To: musl@...ts.openwall.com
Subject: Re: riscv32 v2
On Tue, Sep 8, 2020 at 12:12 AM Rich Felker <dalias@...c.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
