Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4849399imm; Mon, 17 Sep 2018 23:38:46 -0700 (PDT) X-Google-Smtp-Source: ANB0VdZV5mn7RKAiqpNPJ0MPCl97sTc8Fx3A1VYGkOsV1oijeCgLrfR5Kp3Aq7Kl8ZKYjGpJkME4 X-Received: by 2002:a63:9e41:: with SMTP id r1-v6mr25984065pgo.362.1537252726655; Mon, 17 Sep 2018 23:38:46 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537252726; cv=none; d=google.com; s=arc-20160816; b=d+VKphn65xkkfKBlrSSLl44vS/JeEqUxqDMG6zyY+xNLrtPjmu4qlLjxcMrdWdclZb ONm3u4VFEyNbomr4rRT6akhlBzQuAXJuPjlYeUelWg6AfNUlZwjU/p6i+6Yd8mzEVNFj rMpCPFd3MfJCJXG5XyA6KnYg6Dw0yHyAUY8acJrVM4xJgdM5IECApIq5LUJFIoMs3hTr ccWNbyZveMZ1jLmlyYt7zFfBc83/sjAquylyEmDe0h7uGMRA4sSPiLGhVNserFCwT1n3 4i0FKKZw90LnIHqK4gLBKMy+uw2ERCUXoMEnRXyGdy+EJe9U3tUZZbOf5WHEwVLFgUjE hcjw== 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 :references:in-reply-to:mime-version:dkim-signature; bh=QTVTvub5qrtIsSt9FdOr+BP7p/59TzS5tBZwi4OIrgc=; b=cDgr7iZORswJuR+69YpjgJosYybK33FBaxxpGUaVChJ1zidLloKowBhaz8eNc4Q/zo yxseMqBCJbInwHgw/58pYjD+fmkcz2ql/cw9U3YP8EQC2zmE7zA+fdIPTZAp2w91Zo5g cTe29/W7wmDtmU+iKc6nkF6ZMBhBb222Rp26YORwj1QJh/xKUvojAPPkKhm8TDumB9Gm LSf6Xcvm2V2cKnU3WQD+567D1EUfefQskZF88L2v3bGklN7fJjqRTkdQHt/u9xeHWsYg cxHn2sA6v8Ju3iJ/JBWX+DMcuWyfHtcVfa/hIW1g4rshfQkIwhheZSIZqauIKfX0V9TW VurQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=KERJEpCV; 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 37-v6si18171043plq.316.2018.09.17.23.38.31; Mon, 17 Sep 2018 23:38:46 -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; dkim=pass header.i=@linaro.org header.s=google header.b=KERJEpCV; 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 S1728867AbeIRMIK (ORCPT + 99 others); Tue, 18 Sep 2018 08:08:10 -0400 Received: from mail-yb1-f196.google.com ([209.85.219.196]:44331 "EHLO mail-yb1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726696AbeIRMIK (ORCPT ); Tue, 18 Sep 2018 08:08:10 -0400 Received: by mail-yb1-f196.google.com with SMTP id s8-v6so349995ybo.11 for ; Mon, 17 Sep 2018 23:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QTVTvub5qrtIsSt9FdOr+BP7p/59TzS5tBZwi4OIrgc=; b=KERJEpCVAolATTAI5rVq3JQsSqzreYOkfHEZMNmBNSvipT4zUp2dfsREJKmMQzKCVg tik6sU6TzN3ysz4D/THbL9DGis0FomF08EAC0rZyR0pS7GIy2JErPsToJwx2QlgwWBdA bHDcrVB9wb6J2Kmy6ZDFYl4flGnMQXG7pELi0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QTVTvub5qrtIsSt9FdOr+BP7p/59TzS5tBZwi4OIrgc=; b=i/pc7Y4AgcgqrFg97NU2B4tytWxMw4TDZnbnrDwUbIQTf8iegT8XfQhuZ8BJrUfDBK cOAc5+13Zwx2iUyt8jThbq+YIAdasOzShx+gjFMcVlMDev5uDNTM3VqnILo7Vp8o564s LDKTpHnQdLk5UFiQ/fjg5ONJ8ViEACwYR7ha4NnqyISqnQ5/RZiFGwO13jknNuvF1dqg o4B1Xx+v8Wwnm364qIFM/RkFgFgf2KQHO97lFGqW/3zw7il4vCRIVDzbcy/tx5vfR/4n qOjsNAZhbyqcYccKTEtaLJ1yDQEa4+Qbq/kJpB0CpPDbzWGo5z3Y7RJSHxUncW6Q+iTK qQFw== X-Gm-Message-State: APzg51A2OX78ZyhbMCDVpG/zJZxHeEvM1Y3zyrw8lJlHStIo3aTynyNJ aqCoU8L756GL61F7AMaxPHiQ7FAOwZdz2Zz1Z2eLvg== X-Received: by 2002:a25:e548:: with SMTP id c69-v6mr11731496ybh.393.1537252621844; Mon, 17 Sep 2018 23:37:01 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a0d:cc4f:0:0:0:0:0 with HTTP; Mon, 17 Sep 2018 23:37:01 -0700 (PDT) In-Reply-To: References: <1533792466-4227-1-git-send-email-firoz.khan@linaro.org> <1533792466-4227-2-git-send-email-firoz.khan@linaro.org> From: Firoz Khan Date: Tue, 18 Sep 2018 12:07:01 +0530 Message-ID: Subject: Re: [PATCH 1/3] microblaze: Replace NR_syscalls macro from asm/unistd.h To: Michal Simek Cc: Greg Kroah-Hartman , Philippe Ombredanne , Thomas Gleixner , Kate Stewart , y2038@lists.linaro.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Arnd Bergmann , 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 On 9 August 2018 at 12:18, Michal Simek wrote: > On 9.8.2018 07:27, Firoz Khan wrote: >> __NR_syscalls macro holds the number of system call exist in this >> architecture. This macro is currently the part of asm/unistd.h file. >> We have 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 number of system call information. So we have >> two option to update __NR_syscalls value. >> >> 1. Update __NR_syscalls in asm/unistd.h manually by counting the >> no.of system calls. No need to update __NR_syscalls untill >> we either add a new system call or delete an existing system >> call. >> >> 2. We can keep this feature it above mentioned script, that'll >> count the number of syscalls and keep it in a generated file. >> In this case we don't need to explicitly update __NR_syscalls >> in asm/unistd.h file. >> >> The 2nd option will be the recommended one. For that, I moved the >> NR_syscalls macro from asm/unistd.h to uapi/asm/unistd.h. The macro >> name also changed form NR_syscalls to __NR_syscalls for making the >> name convention same across all architecture. While __NR_syscalls >> isn't strictly part of the uapi, having it as part of the generated >> header to simplifies the implementation. > > This macro was in unistd.h in past but it was moved out because it was > causing problem with strace. > > commit 40c2702a02b755e0183b702778331b351f3be20c > Author: Michal Simek > AuthorDate: Mon Jul 8 09:50:24 2013 +0200 > Commit: Michal Simek > CommitDate: Wed Jul 10 07:32:09 2013 +0200 > > microblaze: Move __NR_syscalls from uapi > > > That's why I don't think this is the right thing to do. > I have grepped strace and glibc and none is using this macro that's why > I think it shouldn't be exported via uapi. Thanks for you reply :) Sorry for the delayed response :( I would like to keep __NR_syscalls macro to uapi header in order to simplify the system call table generation script. Otherwise the __NR_syscalls macro need to update manually. That become a problem. Please check the below implementation in uapi file make sense? It is an easy workaround to leave __NR_syscalls macro in uapi/asm/unistd.h and enclose it in #ifdef __KERNEL__ ... ... #define __NR_pkey_free 397 #define __NR_statx 398 #ifdef __KERNEL__ #define __NR_syscalls 399 #endif ... ... - Firoz