[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200908010254.GQ3265@brightrain.aerifal.cx>
Date: Mon, 7 Sep 2020 21:02:54 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: riscv32 v2
On Tue, Sep 08, 2020 at 12:30:27AM +0200, Arnd Bergmann wrote:
> 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.
Oh, really? In that case musl's almost surely broken on microblaze,
and yes it would be another exception.
Rich
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.
