Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp6456192imu; Mon, 21 Jan 2019 09:11:19 -0800 (PST) X-Google-Smtp-Source: ALg8bN7ezKZs1xa/xsg0b6nZFaypSmZeI5OtZcMCRfkYNQAdmYU4ffHW00NO9pxLl4SWwvddgiq+ X-Received: by 2002:a63:d10:: with SMTP id c16mr28973709pgl.382.1548090679482; Mon, 21 Jan 2019 09:11:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548090679; cv=none; d=google.com; s=arc-20160816; b=ITYa/nUJRUmEhGoGqJz8fTIarXC9ZUIAsnn1V5ovn0saXGEUCHp57iRN6N2T1XlGiT /wPLcV8pqt6HnYhYdJbd8VYE3uQTdJNFBuDg32675thszBncRIRgAEfRKBWfIfKhIZ1v qX1DylLNLBVaDdTR84ZuA8tyMhFwa471VLzQ7HLbhbLd4jHxXnoTtS1aS5SrtYKDNKjg FjCyy0NtaTZUsO5SPfYWpGZgGK0aqCtulFvId/2q3DrAKbOdzJez9Bb0uqU5tFCgOdYu 3CLcx93HAEnbwxeXP8ztCv/YrCPW1XgCN5+qs8tRM27cDKMpYgZDnIJvIuSG6iS7J5YQ yzWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version; bh=A3BFzNbMjDWWnmVRt1tolWRl8m0peBLC2YUEivt95tQ=; b=i+w9wTf6wExGvFAL9OdtVFIlA9eopJlOBeVLCfbu2bMisN5t8SFj/8bksULu74a0D4 WGG39viUaThZNtR8U5W3EIdMvBCTdoLh7MlZsBWN42DQnpTvbr+ccGk2g2zSoyo8GWPT YHWMkaf3KsASYZMt94Q8i6GYHL80VznhJ/H53IpNrZJ708N7W/zYkLHgXIvm2mnfSrKk ZUc2PWzXddjyqk4vYe4ofdr9rXTmuioaKoNR+amVQPZn0zg1igxtbWWD6vJwx/2ZHkMR uMDSwahCtk3Kp0CkvNK+khpOowh5rCdZRKAP2XbzurKaUSMcPIN1ztFSnYC1BSDR97E5 2zmg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w5si12509330plz.419.2019.01.21.09.11.02; Mon, 21 Jan 2019 09:11:19 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727490AbfAURIk (ORCPT + 99 others); Mon, 21 Jan 2019 12:08:40 -0500 Received: from mail-qt1-f194.google.com ([209.85.160.194]:36755 "EHLO mail-qt1-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726068AbfAURIj (ORCPT ); Mon, 21 Jan 2019 12:08:39 -0500 Received: by mail-qt1-f194.google.com with SMTP id t13so24320894qtn.3; Mon, 21 Jan 2019 09:08:37 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=A3BFzNbMjDWWnmVRt1tolWRl8m0peBLC2YUEivt95tQ=; b=LuC+BFBFDarHHTq/4HS7If4XzMJzl5Y96wDGxXA1zsJNjtZAiNRzDaRR8ekZiU8LSE QS3kbyCHfwi/mEWiu2LUgLynFpULg4hk/VI8GjIyoQc3hiLdUC0mxTuOLNpJk0aIb/us whY4+48NwO5sQvnEu5DtJS/OV8l4kGR9MebOjji6uSM8tTn/O2M2cIVb2eadFHNKl5N/ vwXby02Fm1U6clyrSazy4WnOUEC7yf3uvOlcBc4XOtijAFoXHTwy+p1TPgMjMpafSKbN bfIJlT5MvCwer3jn/oSWX+uclP7ajJpDeEiS2m3MINXRcpZnt58jj8U7cB+cAD8LQ5ON +l6Q== X-Gm-Message-State: AJcUukefvxqZugOhEo7ulSLLc2wICtmh/ul1Bl+K6SeOLIEpQg7woe5D UNmyX2J2gzymAZ3Rvr8FiLsmqLvrid8jdqb2TsA= X-Received: by 2002:ac8:1d12:: with SMTP id d18mr27232408qtl.343.1548090517294; Mon, 21 Jan 2019 09:08:37 -0800 (PST) MIME-Version: 1.0 References: <20190118161835.2259170-1-arnd@arndb.de> <20190118161835.2259170-30-arnd@arndb.de> <20190119142852.cntdihah4mpa3lgx@e5254000004ec.dyn.armlinux.org.uk> In-Reply-To: From: Arnd Bergmann Date: Mon, 21 Jan 2019 18:08:20 +0100 Message-ID: Subject: Re: [PATCH v2 29/29] y2038: add 64-bit time_t syscalls to all 32-bit architectures To: Geert Uytterhoeven Cc: Russell King - ARM Linux admin , Andy Lutomirski , y2038 Mailman List , Linux API , LKML , linux-arch , Matt Turner , Catalin Marinas , Will Deacon , Tony Luck , Fenghua Yu , Michal Simek , Paul Burton , Helge Deller , Benjamin Herrenschmidt , Michael Ellerman , Martin Schwidefsky , Heiko Carstens , Rich Felker , "David S. Miller" , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , X86 ML , Max Filippov , Andrew Morton , Deepa Dinamani , "Eric W. Biederman" , Firoz Khan , alpha , linux-arm-kernel , "linux-ia64@vger.kernel.org" , linux-m68k , linux-mips@vger.kernel.org, Parisc List , linuxppc-dev , linux-s390 , Linux-sh list , sparclinux , Network Development , Linux FS Devel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 21, 2019 at 9:19 AM Geert Uytterhoeven wrote: > On Sat, Jan 19, 2019 at 3:29 PM Russell King - ARM Linux admin > wrote: > > On Fri, Jan 18, 2019 at 11:53:25AM -0800, Andy Lutomirski wrote: > > > On Fri, Jan 18, 2019 at 11:33 AM Arnd Bergmann wrote: > > > > On Fri, Jan 18, 2019 at 7:50 PM Andy Lutomirski wrote: > > > > > > Can we perhaps just start the consistent numbers above 547 or maybe > > > block out 512..547 in the new regime? > > > > I don't think you gain much with that kind of scheme - it won't take > > very long before an architecture misses having a syscall added, and > > then someone else adds their own. Been there with ARM - I was keeping > > the syscall table in the same order as x86 for new syscalls, but now > > Same for m68k, and probably other architectures. > > > that others have been adding syscalls to the table since I converted > > ARM to the tabular form, that's now gone out the window. > > > > So, I think it's completely pointless to do what you're suggesting. > > We'll just end up with a big hole in the middle of the syscall table > > and then revert back to random numbering of syscalls thereafter again. > > I believe the plan is to add future syscalls for all architectures in a > single commit, to keep everything in sync. Yes, that is the idea. This was not realistic before, since each one of the old architectures had its own way of describing the system call tables, and many needed a different set of quirks. Since (almost) everything is now converted to the syscall.tbl format, we have removed all obsolete architectures, and a lot of the quirks (x32, spu, s390-31) won't matter as much in the future, I think it is now possible to do it. We could even extend scripts/checksyscalls.sh to warn if a new syscall above 423 is not added to all 16 tables at the same time. > Regardless, I'm wondering what to do with the holes marked "room for > arch specific calls". > When is a syscall really arch-specific, and can it be added there, and > when does it turn out (later) that it isn't, breaking the > synchronization again? We've had a bit of that already, with cacheflush(), which exists on a couple of architectures, including some that use the first 'arch specific' slot (244) of the asm-generic table. I think this will be rare enough that we can figure out a solution when we get there. > The pkey syscalls may be a bad example, as AFAIU they can be implemented > on some architectures, but not on some others. Still, I had skipped them > when adding new syscalls to m68k. > > Perhaps we should get rid of the notion of "arch-specific syscalls", and > reserve a slot everywhere anyway? I don't mind calling the hole something else if that helps. Out of principle I would already assume that anything we add for x86 or the generic table should be added everywhere, but we can make it broader than that. Arnd