Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 8 Sep 2020 00:30:27 +0200
From: Arnd Bergmann <>
Subject: Re: riscv32 v2

On Tue, Sep 8, 2020 at 12:12 AM Rich Felker <> 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.


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.