Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp327918imu; Mon, 19 Nov 2018 23:23:16 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vtkarj63CofUQ+hdJNgKKY0klaU7WncOXa3w75QMMujWRk4sXYGu7DSh3TdqJFJjnMsgE8 X-Received: by 2002:a63:ba48:: with SMTP id l8mr912632pgu.72.1542698596419; Mon, 19 Nov 2018 23:23:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542698596; cv=none; d=google.com; s=arc-20160816; b=DousWpi4tSfgOyoGVZXdft1HpmHEg+sWVnnKEMIjNHO4McuxWEJq1/uajGpap+6lku q40fQGjnYtcRzBQWJ5DDLsGGDVfpXtVlU+EQWd2yCkYbhkNyLDs4kHEd/j1Z6XBnuH7A A/vjlI73+fGYohsyTlkHx/HAYr840ubgNojmrZax07vvlql0dUK/zVRElXkEiPpB2Bus poCvTydkhTLdKGn8L/eakXbEU9zBWXFsGTqpXUJqrE62tffCwVQW37pTC4q6pZzsYQZ3 zwfolz9wcafBiJQG5eNx+u5+uTULkHWnMh0brSU1QPd1dD1CyICHo9cn6OOAlyckhwbO sxcQ== 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:dkim-signature; bh=njRB5YrwvPAuwvTzkXx47jt5XkZKXLf9VfbAmPMwazI=; b=CIDKiv7v61aBz+pZ7MIDNTCNZvSIG/IgOS0+eJjriT+sJsKvTdJZejuw5AGsffkIEY q66ZlXmMlGCjQtqhXQfuWMsXo+5rFMtz73ewbYF/882Bbmwd8ceLqCYzCp6xqA3axvsk jRosKvAks+km6MVgvGhZdlLYMJvzhvKLKUqQ4wcxygAuqJhEuT1ELqEAOZciLpjC0zb7 J4K1Gdbn5pZDEWW4/NDcRpICG/W2Ni/JBuHAgzkPgz4Ae/6B9xpE+9ZdbMGPH6OlH2AC FliNOqfhniLRD9j97yXX5p3m/c0beknFJVMwocWBoUoWm5iPFlaS19MaQQHmfvNkPg5I NQkQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=N78nMXqx; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f13si13028082pln.368.2018.11.19.23.23.01; Mon, 19 Nov 2018 23:23:16 -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; dkim=pass header.i=@linaro.org header.s=google header.b=N78nMXqx; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732555AbeKTRdb (ORCPT + 99 others); Tue, 20 Nov 2018 12:33:31 -0500 Received: from mail-it1-f195.google.com ([209.85.166.195]:33163 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728703AbeKTRdb (ORCPT ); Tue, 20 Nov 2018 12:33:31 -0500 Received: by mail-it1-f195.google.com with SMTP id p11-v6so9302070itf.0 for ; Mon, 19 Nov 2018 23:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=njRB5YrwvPAuwvTzkXx47jt5XkZKXLf9VfbAmPMwazI=; b=N78nMXqxaaWx2NWIvnHMx1rZilyaymSwztLimGi4M6MooVrmnLfqJi7piOFUmbwUC8 dKYM2sxqAUY39u9tG3RqxtN/af+tDiL3vosSCyaV0JMkIR86RqF/e2NkJ6WVJtXDbA0m eXbnrCw3wnKJKRdiz8FjSrz36OEH6W4vYKnRc= 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=njRB5YrwvPAuwvTzkXx47jt5XkZKXLf9VfbAmPMwazI=; b=bMmqxyH02cNahPXYBlhM8KgnQssz4L4EEevPJ+7idmbqQvq7yePSVSg6XRFcdQCROG hvKNihxnqmd9YTrlVSJLn6fQ/wNJ7N8PVTnxIzeDb5BcBTx9up5b2nJ1jaHvWJv206kV 4x3fHgqFp/jrX1toPsjT1j1f2dR+dVasFuf9I7+LxNh2GHuHx5f/0GyOIuYz631J7dAD ljzHAITOy1hVri1O2n6UjRScOH1hG2YqqgDxjIxGtgG0OmR0ClmSd+q5qPYuP94FHE5D D4xM4lhXsYo/TA4X3mviiavZ7DjgZyvvO0oNXEfNcT5m0MAYm+z8ZuLKPAWM87qDZVpm 80ng== X-Gm-Message-State: AGRZ1gLZbCENLpSGz1UZEe0xH/lpbfcU/WFOiOdmT0QIb9Mk8QwZd7Hj SfLcJBmmYrEU2cmDm8HsZfRQKeYwdlABUY3CmJKQwA== X-Received: by 2002:a02:788:: with SMTP id f130-v6mr807025jaf.58.1542697556148; Mon, 19 Nov 2018 23:05:56 -0800 (PST) MIME-Version: 1.0 References: <1542169930-24118-1-git-send-email-firoz.khan@linaro.org> <1542169930-24118-2-git-send-email-firoz.khan@linaro.org> In-Reply-To: From: Firoz Khan Date: Tue, 20 Nov 2018 12:35:44 +0530 Message-ID: Subject: Re: [PATCH v3 1/3] sh: add __NR_syscalls along with NR_syscalls To: Arnd Bergmann Cc: linux-sh@vger.kernel.org, Yoshinori Sato , Rich Felker , Greg Kroah-Hartman , Philippe Ombredanne , Thomas Gleixner , Kate Stewart , y2038 Mailman List , Linux Kernel Mailing List , Linux-Arch , Deepa Dinamani , Marcin Juszkiewicz 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 Hi Arnd, On Mon, 19 Nov 2018 at 22:21, Arnd Bergmann wrote: > > On Wed, Nov 14, 2018 at 5:32 AM Firoz Khan wrote: > > > > NR_syscalls macro holds the number of system call exist > > in sh architecture. We have to change the value of NR- > > _syscalls, if we add or delete a system call. > > > > One of the patch in this patch series has a script which > > will generate a uapi header based on syscall.tbl file. > > The syscall.tbl file contains the total number of system > > calls information. So we have two option to update NR_sy- > > scalls value. > > > > 1. Update NR_syscalls in asm/unistd.h manually by count- > > ing the no.of system calls. No need to update NR_sys- > > calls until we either add a new system call or delete > > existing system call. > > > > 2. We can keep this feature it above mentioned script, > > that will count the number of syscalls and keep it in > > a generated file. In this case we don't need to expli- > > citly update NR_syscalls in asm/unistd.h file. > > > > The 2nd option will be the recommended one. For that, I > > added the __NR_syscalls macro in uapi/asm/unistd_32/64.h > > along with NR_syscalls which is moved to asm/unistd.h. > > The macro __NR_syscalls also added for making the name > > convention same across all architecture. While __NR_sys- > > calls isn't strictly part of the uapi, having it as part > > of the generated header to simplifies the implementation. > > We also need to enclose this macro with #ifdef __KERNEL__ > > to avoid side effects. > > > > Signed-off-by: Firoz Khan > > Looks correct to me, but since there are only three references to > 'NR_syscalls' in arch/sh, I wonder if we should just replace it with > __NR_syscalls in the same patch. This is the approach I had initially, But someone pointed out that doing this way - #define NR_syscalls __NR_syscalls would be better. The only difference is here the number of occurrence 3 and there 5-7 occurrence of NR_syscalls. Thanks Firoz > > Arnd