Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp416714imu; Tue, 20 Nov 2018 01:04:38 -0800 (PST) X-Google-Smtp-Source: AFSGD/XYvjtgZdo4sDiGLrEHCL5qJkppxwTiLxk+Zo26EBqhnnIw2iphUNVAH3YH0ADg+I21iC6Z X-Received: by 2002:a63:e20a:: with SMTP id q10mr1146312pgh.206.1542704678946; Tue, 20 Nov 2018 01:04:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542704678; cv=none; d=google.com; s=arc-20160816; b=wZ3nCVKAV7ve1bEH/s1epqpU0ANP+IKLNUNhNt+7TkBdtYmVEXqRkEvbDQlW5+Q+uc bqTBEAbgLWdPCF/k8GYB9ZGCSIfhv81VQwPQAyXoekAu0YNHyy3QGgPraGZMZ1F9igrc Cw7V3oIdxYSyuNRtZn0s0yR7TEpcROHrsSQlprTGabzwkaSg50E3usvRaqjdt0b7o17i fYpCqStAfuZbJZtcZt5OJTTxl49SwykYNA9TStOypkpxb/CZnd0Ovm9H31tacKmRIUu9 hWnQ7w+NerwGUxVNQMnvpVGv+iSLzYvrLL0D7qDwOB8q9Inc8qP1o9v6rFE+SejtfeJr evWA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :in-reply-to:date:references:subject:cc:to:from; bh=ni06nas83fuDeYTvJelk+SgujToLp3dwDFrPQHptyx8=; b=dmG4uwIzf00Mvq2XNx4HVVgAXDHe9VnMsKPsu7yfr20r5ZzLnQ6ikM6g5IUrQGIXAb X0YvHSh1q8Xh5AaAcwi22GDLAbuKXWapU1ZBHNNnnmLJCOORN7EiEDVTXl56eq12mBsA oDVeYPU/7clzmhQ+bQxLsNzaDh+0uNJ0YrcKh1Ezb+eKZ/Rn91W4I2QLd7tJrbeSSdO/ eA2iKMFuWr26PC06/+tKKHpvy8f5Qw9u82nR6nAgJ3gRD2VjlyNHvUTD2gjSDKKSV8av Z3E9XnFFPvK0b95xHVxOL5QO3bRFMh9qJ4ccxJqwgxTInxnbLdkt2tLnQ1qLGeA4HM+C BGOA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a90si6074298plc.314.2018.11.20.01.04.22; Tue, 20 Nov 2018 01:04:38 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726890AbeKTTbr (ORCPT + 99 others); Tue, 20 Nov 2018 14:31:47 -0500 Received: from mx1.redhat.com ([209.132.183.28]:59446 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726039AbeKTTbr (ORCPT ); Tue, 20 Nov 2018 14:31:47 -0500 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6EB1EBDF7; Tue, 20 Nov 2018 09:03:44 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-116-60.ams2.redhat.com [10.36.116.60]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E24C75D75E; Tue, 20 Nov 2018 09:03:38 +0000 (UTC) From: Florian Weimer To: Andy Lutomirski Cc: X86 ML , LKML , Borislav Petkov , Peter Zijlstra , Tycho Andersen , Daniel Colascione , "Carlos O'Donell" , Rich Felker Subject: Re: Cleaning up numbering for new x86 syscalls? References: Date: Tue, 20 Nov 2018 10:03:30 +0100 In-Reply-To: (Andy Lutomirski's message of "Mon, 19 Nov 2018 16:22:49 -0800") Message-ID: <87efbggly5.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Tue, 20 Nov 2018 09:03:44 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * 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. Thanks, Florian