Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2408691imu; Wed, 21 Nov 2018 11:09:19 -0800 (PST) X-Google-Smtp-Source: AJdET5fn6dC7JZyM4ESnFf8gerUdGr1RvYRL44hyq7dhVtzTuxBN7kXekJ1PhoT3NonQyxYQiMsP X-Received: by 2002:a62:35c2:: with SMTP id c185-v6mr8169514pfa.82.1542827359129; Wed, 21 Nov 2018 11:09:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542827359; cv=none; d=google.com; s=arc-20160816; b=gLzCccltGxl6AWW/1bSQyX/N9wkF4d+9djnmzVtFLT8l48jF2pkltqWCqhhk4Ph6go Vq8+ZUdCapjkvWUSo6n4nJdtS5CQjqiGKXzm0kO4yGrLv7uF50UnN7M0GX7M7Xcj7uss LptOAdrHfRSLmAUcIQBrqthqT/FyXP2dciCU5jnogjWA/LxtrJ0YSBU3jdCus+ngGGGS lJl74IWOsR8JmztB3M97EPirUxHHMqdHjE+vguJYzq8xBHFBs/CWt3WMKD+BATwZjbOn 9VagEPdYI3H49/a4tYcyoJlCH7YvKdZgvzKn4/eU3lCBgkYYys++gIQVzTkuIEs9OTkY 5hfA== 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=QaCVNqyJbaP9O+t90Hd4/wjgzX3V51X1m72Wc6ZVnA0=; b=CxGkO4euXmSMQxWMrCQ5ZVJyPLb5djaOerMFaYfHdr/EumALKK6scCHTtSp1zBAdOG j+JxU1Bj16ELegioOU0k0vEmLLpXmBmqdVpS8K/FWJQIyvHRtsG+NdLvkeg3w6SkslBp mk9DzCAObiJLLvzT0/L/95IUzHTQcsJ7utdfE02APRSFZT2smI88vkKSiNOlA2W00yMY YwMMWC1TFMpjCE9r0z7s9ojC/an9VY/m3F2FgEG0OlPTgFvA6LJmudpx85r25nKmqEyL qU4WuhGZRb9OwtcVh11HCWO796mGukYUFhSBTBqkCJk6iYobp7mhxui/RBpcMfSADdQ2 +bYg== 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 x6si14890575pln.425.2018.11.21.11.09.03; Wed, 21 Nov 2018 11:09: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 S1730606AbeKVD7f (ORCPT + 99 others); Wed, 21 Nov 2018 22:59:35 -0500 Received: from mail-qk1-f195.google.com ([209.85.222.195]:34055 "EHLO mail-qk1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726711AbeKVD7f (ORCPT ); Wed, 21 Nov 2018 22:59:35 -0500 Received: by mail-qk1-f195.google.com with SMTP id a132so5367655qkg.1 for ; Wed, 21 Nov 2018 09:24:17 -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=QaCVNqyJbaP9O+t90Hd4/wjgzX3V51X1m72Wc6ZVnA0=; b=O3eLW3c61veM4Oc5/9KR+SHW4UiEieYF0IIn+J0JBg/U+Rkbitia4dC5TqAYrUDluW mf1vgU9FJaBgRKdGvV8+MkBefx14ZnsvLBl12m2m4PzNVEpqi/xQjDE+XnplBX9qn3ib syoXMrpBsXDKfV0TyHGdgBYOjpXhVs13bel/gvFxKillF/78RCGDr51q+ATtTji8wXfd wggYLpo7JPqnreu7ugjfxa04F+bwzCSQ8VWmM1SI1xRzHQNwOLplfXY0I7/nbjw1Mnjr ny7/8thPB6I9tVpt0qqa3IfeXYPOI181jRYRsPZ0DaN/+OBlSnsYS8XycnNAI7NiR6Fo 7qOQ== X-Gm-Message-State: AA+aEWa7E6UUNnBnkjeOGJGwggcAJCSCL4AK6xg0O87LM+UhYY/LNLSH HWzWJC5ybD4ESztJYiotcDt7mpX1LX6S/PEVEwk= X-Received: by 2002:ae9:e102:: with SMTP id g2mr6056730qkm.343.1542821057253; Wed, 21 Nov 2018 09:24:17 -0800 (PST) MIME-Version: 1.0 References: <87efbggly5.fsf@oldenburg.str.redhat.com> In-Reply-To: From: Arnd Bergmann Date: Wed, 21 Nov 2018 18:23:50 +0100 Message-ID: Subject: Re: Cleaning up numbering for new x86 syscalls? To: Andy Lutomirski Cc: Florian Weimer , "the arch/x86 maintainers" , Linux Kernel Mailing List , Borislav Petkov , Peter Zijlstra , Tycho Andersen , Daniel Colascione , carlos@redhat.com, Rich Felker 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 Tue, Nov 20, 2018 at 4:35 PM Andy Lutomirski wrote: > > On Tue, Nov 20, 2018 at 1:03 AM Florian Weimer wrote: > > > > * Andy Lutomirski: > > > > > 5. Adjust the scripts so that we only have to wire up new syscalls > > > once. They'll have a nr above 1024, and they'll have the same nr on > > > all x86 variants. > > > > Is there a sufficiently sized gap on all other architectures as well? > > The restriction to the x86 variants seems arbitrary to me. > > > > Fair point. We have this shiny "generic" syscall list. Maybe we can > get x86 synced up with it for new syscalls. The generic table is already a subset of the x86 tables, so there should be no need to sync up the contents. It's more critical on other architectures that currently lack a number of the syscalls that got added in asm-generic and x86 recently, so I'd like to synchronize these all and add the missing calls to ensure that each architecture has at least all the calls from asm-generic table. After that, I would hope to come up with a way to add future numbers to all tables together, either using the same numbers everywhere (plus an offset where necessary, e.g. mips), or even have an include file logic so we only need a single file for future additions. Note: for y2038, we will have to add around 20 to 25 syscalls to each 32-bit architecture, plus another 10 for those that lack the separate sys_ipc calls. Arnd