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.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,
	RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham
	autolearn_force=no version=3.4.4
Received: (qmail 21691 invoked from network); 14 Apr 2022 09:36:23 -0000
Received: from mother.openwall.net (195.42.179.200)
  by inbox.vuxu.org with ESMTPUTF8; 14 Apr 2022 09:36:23 -0000
Received: (qmail 23870 invoked by uid 550); 14 Apr 2022 09:36:20 -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 23836 invoked from network); 14 Apr 2022 09:36:19 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org;
	s=k20201202; t=1649928967;
	bh=7rF0itdYv9mVNtqRTXrXV1ENYCeVENfOI771ccBMHk4=;
	h=Date:From:To:Cc:Subject:References:In-Reply-To:From;
	b=DMBtwGKI6FHOLN37uP/bIfOe+yqdkfbslH1ZTXNGDuj16wN+WuvET4D0+UKB6yfTa
	 /QhoqqtPf3traJ8OxJCAemiSJMxqbjHabb4MqtFQAC8+74z+P0bbUitAgBNFMxuJm8
	 HVk+V3DnnCX2Prmz//v+N0Gf4ypv/Cjkh8Z+Or6Vc0avnrWVzeGrOcAwFL6xQsJkE0
	 1Gm0bzc2quBMiIIzW6Cgsg2AdDgsOO/C+ejedk3amvXAoaIa6fp3EBq1B6/csoF2W8
	 DECi75n/7xRwtzg86jsPDhsrRcY1+VI4zb6z4ldV5Pe7m1CntBS8MP6SmRAdBq1Gt3
	 W2cZIDwG+a2pQ==
Date: Thu, 14 Apr 2022 11:36:04 +0200
From: Christian Brauner <brauner@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: musl@lists.openwall.com
Message-ID: <20220414093604.dfhmhehwx65p3ndr@wittgenstein>
References: <CAK8P3a17Mrqr36Typ1F_pCUEFjG5PLQ+xrDmDdSB2M0GGK8qfw@mail.gmail.com>
 <e1f6d8cb-da12-0f0a-4929-108497119b8a@loongson.cn>
 <CAK8P3a16=jw4LzsAeRRoPA2-Z5SyP3ajWH=zSuuwgOt9POn-6A@mail.gmail.com>
 <20220409131939.GK7074@brightrain.aerifal.cx>
 <20220409133044.GL7074@brightrain.aerifal.cx>
 <CAK8P3a2=bohTTJJNaMju=mOfFOv8_xjTcQZ909LRE45BudLjGQ@mail.gmail.com>
 <20220413072606.44wwkk64xshn5mmm@wittgenstein>
 <CAK8P3a3dJ_NvXZzpFX-nj1UUeQzviMHS+BKMSXf+KTyAqYOiqw@mail.gmail.com>
 <20220413090425.rmprwzpgpztianin@wittgenstein>
 <CAK8P3a0Mc9WEwcNEQfMn1iTLf0syBFJQ29+j3KBt-P=ZYg76NQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAK8P3a0Mc9WEwcNEQfMn1iTLf0syBFJQ29+j3KBt-P=ZYg76NQ@mail.gmail.com>
Subject: Re: [musl] Re: add loongarch64 port

On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote:
> On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner <brauner@kernel.org> wrote:
> > On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote:
> > >
> > > The normal rule is that we don't define obsolete system calls in new
> > > architectures when an improved variant has been added, e.g. oldoldstat,
> > > oldstat, stat, newstat and stat64 have all been replaced by statx over
> > > the decades. I was expecting the same to be true for clone(), but if
> > > clone3() is not meant as a replacement, we can keep both around.
> >
> > No, I agree with you on this and would like to only implement clone3()
> > on new architectures.
> >
> > What I'm asking is whether removing the size == 0 check is enough to
> > unblock the missing behavior and whether you'd be on board with removing
> > the check?
> 
> I think that's ok here, since we'd only rely on this for loongarch64 at the
> moment. It would probably need to be documented in the man page
> as a special case though.

Ok, I'll try to have a patch ready early next week since I'm currently
out sick.