From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI,
	RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 30746 invoked from network); 8 Sep 2020 01:03:16 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 8 Sep 2020 01:03:16 -0000
Received: (qmail 30281 invoked by uid 550); 8 Sep 2020 01:03:07 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 30260 invoked from network); 8 Sep 2020 01:03:06 -0000
Date: Mon, 7 Sep 2020 21:02:54 -0400
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Message-ID: <20200908010254.GQ3265@brightrain.aerifal.cx>
References: <e792658a-fbaa-48bd-8704-7f9d2ec5a4ef@www.fastmail.com>
 <68b5e735-45be-413f-8153-cb97dd5967cd@www.fastmail.com>
 <20200907180636.GM3265@brightrain.aerifal.cx>
 <CAK8P3a1jcoT19D2kSepf8FEwkD5ymnWPm797dHUb+8U_xkMQnA@mail.gmail.com>
 <20200907214554.GO3265@brightrain.aerifal.cx>
 <CAK8P3a2kTEC3rDVD0VQLXvYAEuD24QtXLMxDQ=h_L45Fb8NdEw@mail.gmail.com>
 <20200907221151.GP3265@brightrain.aerifal.cx>
 <CAK8P3a1J9QrqFvFagr4aaXTK2ma_6vaRFMR9GCUgY-wHtHcP3w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAK8P3a1J9QrqFvFagr4aaXTK2ma_6vaRFMR9GCUgY-wHtHcP3w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [musl] 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@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.

Oh, really? In that case musl's almost surely broken on microblaze,
and yes it would be another exception.

Rich