Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752408AbdFTVO5 (ORCPT ); Tue, 20 Jun 2017 17:14:57 -0400 Received: from mail-pf0-f196.google.com ([209.85.192.196]:36537 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751773AbdFTVOz (ORCPT ); Tue, 20 Jun 2017 17:14:55 -0400 Date: Tue, 20 Jun 2017 14:14:53 -0700 (PDT) X-Google-Original-Date: Tue, 20 Jun 2017 13:51:26 PDT (-0700) From: Palmer Dabbelt To: Arnd Bergmann CC: ynorov@caviumnetworks.com CC: james.hogan@imgtec.com CC: catalin.marinas@arm.com CC: linux-arm-kernel@lists.infradead.org CC: linux-kernel@vger.kernel.org CC: linux-doc@vger.kernel.org CC: kilobyte@angband.pl CC: schwab@suse.de CC: pinskia@gmail.com CC: bamvor.zhangjian@huawei.com CC: cmetcalf@ezchip.com CC: cmetcalf@mellanox.com CC: fweimer@redhat.com CC: heiko.carstens@de.ibm.com CC: james.morse@arm.com CC: joseph@codesourcery.com CC: maxim.kuvyrkov@linaro.org CC: Nathan_Lynch@mentor.com CC: Prasun.Kapoor@caviumnetworks.com CC: ramana.gcc@googlemail.com CC: sellcey@caviumnetworks.com CC: agraf@suse.de CC: broonie@kernel.org CC: christoph.muellner@theobroma-systems.com CC: davem@davemloft.net CC: geert@linux-m68k.org Subject: Re: [PATCH 03/20] asm-generic: Drop getrlimit and setrlimit syscalls from default list In-Reply-To: Message-ID: Mime-Version: 1.0 (MHng) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2044 Lines: 40 On Tue, 20 Jun 2017 08:27:36 PDT (-0700), Arnd Bergmann wrote: > On Tue, Jun 20, 2017 at 4:54 PM, Yury Norov wrote: >> On Tue, Jun 20, 2017 at 04:20:43PM +0200, Arnd Bergmann wrote: >>> On Tue, Jun 20, 2017 at 3:37 PM, Yury Norov wrote: >>> > On Mon, Jun 19, 2017 at 11:10:23PM +0100, James Hogan wrote: >>> >> On Mon, Jun 19, 2017 at 11:58:41PM +0200, Arnd Bergmann wrote: > >>> > I would also notice riscv people and welcome to the discussion. >>> > >>> > As there is more than 1 arch that goes to be added to linux soon, >>> > maybe it's better to upstream my ans James' patches separately >>> > from other ilp32 patches? Arnd? >>> >>> Do you mean upstream those two patches slightly later? That's >>> fine with me, I don't care much whether the old new stat is part >>> of the syscall table for arm64-ilp32 or not, I'd leave that up to >>> you, depending on whether you want to do the rework or not. >> >> I mean that if we want to deprecate rlimit and stat syscalls for >> architectures that are under development now, it's better to upstream >> patches that actually deprecate it as early as possible. > > Makes sense. > >>> I suppose the arm64-ilp32 could benefit from not having to support >>> the old arm32 stat structure, but doing the new syscalls based on >>> statx could delay the glibc port some more, as there are some open >>> questions about how that would best be integrated. >> >> OK. Let's leave things as is. But then I don't see any reason to >> add unxstat patch to ilp32 series if ilp32 will not disable it. > > Right, that's what I meant: let's leave the rlimit patch in your series > as it matches the work you have already done, and is the right > thing to do, and let's do the unxstat patch separately so it doesn't > cause you extra work. Thanks for the heads up. We're in the process of submitting glibc now with the goal of getting into 2.26, so I think that means we'll be stuck with stat. I'm perfectly happy to deprecate whatever is feasible, though.