Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp1740631imd; Thu, 1 Nov 2018 23:05:13 -0700 (PDT) X-Google-Smtp-Source: AJdET5fz0VDZFKqoAOdVrueC8akfNP2E3SKeNX+Qe8MqzmLe4FQ2UN72rvY1BPaED6LuuZAjUr72 X-Received: by 2002:a17:902:d88f:: with SMTP id b15-v6mr7196466plz.207.1541138713170; Thu, 01 Nov 2018 23:05:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541138713; cv=none; d=google.com; s=arc-20160816; b=iKkXppBtU+W8O3dCMEOtHQWyvoiBg9MMTFDJOE9SobtmJbwiaq98jJDtlYaWo+fSKr xWP8O5cd8+w2tXkjuopNtWvF8y7AT62lFMiSXz9Y8AodaMXCBpt9tXplH7wKWPD49Xnn NRvVAIyEnZ9zTX9ZYc4ruO2dw1bO+fydPjubNPwypdvPpfJWanSDk1bvCFZZUPr6MrWQ qDoovw+l9iLEGnXC0WsC81NhFlQvdX/v++1eMtSO1+vRLTSdx8+hav7xX6ukJxzwGMuM Rq+pqQB4u0Nrhj/yuDDBaALSE1x3VefSjYOpmrFTV3kAjHSlnH4u9bys873e+No3OvGI NxKw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date; bh=TFcj4sq/saIMuoaxdEsjPdf3sEGBEfnWH18Gkesdg1Q=; b=uWUb4OZA/5k9aSNmejwWIEmSRmEFo0SLpuUiocvcNfpGVOtPAXQclYo0ahZW/OmA8g uZb0Xh+SR+7dyRdzRGKtf4mXNaIBGFGVzZsb6IKTaNJkP7MpMaRgvGIAhtgraDgtQtzq ZhxBnRYQJ0/hsaa7UzSaibGKwWtRUlmNFj5uRwNPCP0dhyffYXAWn/A5GmHDmh9D8pKD 66QQ9BkLl491gjWD8k/NEdghoohn8VnBq9tEUL/bJOXV6boFwCHobaDveWP0XHTS4FsF CCc+mJDE0lm1m5GJOqlavwSYMcmm5Nic46izWTf1rG7vvXUZw4z8YU2Aeav8w6dee88o IXNA== 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 x3-v6si32598164pgj.425.2018.11.01.23.04.58; Thu, 01 Nov 2018 23:05:13 -0700 (PDT) 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 S1728289AbeKBPKb (ORCPT + 99 others); Fri, 2 Nov 2018 11:10:31 -0400 Received: from shards.monkeyblade.net ([23.128.96.9]:54154 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727804AbeKBPKb (ORCPT ); Fri, 2 Nov 2018 11:10:31 -0400 Received: from localhost (unknown [IPv6:2601:601:9f80:35cd::cf9]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 59A9314071A8D; Thu, 1 Nov 2018 23:04:30 -0700 (PDT) Date: Thu, 01 Nov 2018 23:04:27 -0700 (PDT) Message-Id: <20181101.230427.364286844194487248.davem@davemloft.net> To: firoz.khan@linaro.org Cc: sparclinux@vger.kernel.org, gregkh@linuxfoundation.org, pombredanne@nexb.com, tglx@linutronix.de, kstewart@linuxfoundation.org, y2038@lists.linaro.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, arnd@arndb.de, deepa.kernel@gmail.com, marcin.juszkiewicz@linaro.org Subject: Re: [PATCH v2 3/4] sparc: add system call table generation support From: David Miller In-Reply-To: References: <1541080391-3890-4-git-send-email-firoz.khan@linaro.org> <20181101.133315.47887636039827313.davem@davemloft.net> X-Mailer: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Thu, 01 Nov 2018 23:04:30 -0700 (PDT) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Firoz Khan Date: Fri, 2 Nov 2018 11:09:57 +0530 > On Fri, 2 Nov 2018 at 02:03, David Miller wrote: >> >> If sys_nis_syscall for the compat syscall shows up in a situation where the >> native 32-bit syscall does have an entry, that's a BUG and the script should >> point this out so that the bug can be fixed. > > syscall.tbl is the input to the script, so the developers has the > responsibility to fill the table > properly. I don't know, we have to write a script which has to be > smart enough to catch the > wrong syscall entries. It does not need anything "smart", it just needs to see that sys_nis_syscall in the "compat" column just as my eyes noticed them in your patch. It can be completely automated.