Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp5019706imm; Tue, 18 Sep 2018 03:05:16 -0700 (PDT) X-Google-Smtp-Source: ANB0Vdazk49TOLGvTBBEp94gvNOVrYYKK/y8PrYZYtke88mBwbzlTXT/hVznY3y88O72cGY0slgk X-Received: by 2002:a63:9e0a:: with SMTP id s10-v6mr27518074pgd.326.1537265116619; Tue, 18 Sep 2018 03:05:16 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537265116; cv=none; d=google.com; s=arc-20160816; b=0isCfyY69uxp/3za9Rx6eMHxMMPQyAYZ/+cWskHUAAh0KJo9UtoDt6jNeu1qoZ5bbJ XfH+RGmWr/iTHu5OqvNOHfmEDzENBKg9505Lf+TBPFkYyPckp290QXirVNXsDAqHpbgf uqTqzUj49fJY9TSr8eRjf6PHUfU8qN1STNcPl1M7QEhbvE8C01p9oo4b3nr68cyxWj8c M+rrW2sZmBTUjbqdpS5SpOy+bDPT+3syD3oBhjAbEHoYqZ6myTlq6+9pdxugh67yijjA kH1GInX0cOHWJwpdshn+6LvMQSjgKDaWzv/mOjkQ1zPqIAfIAb+SPwwSd9KtHXgPhwKv KWIA== 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=hSk3B4twbMDvFSuPlrXne9UgVExFWzhUGu+0rETXsn4=; b=HIc7FDgIjjM1VAozMw+YYqbHMMbKJghmpGlyCt1o5moo78tgl3DhT++H55nXr6sElR mhYhI3tCxn2slYdfVxaIue+x+Ntt3ZsDI+rjJQXI7Y/HILjlhjnnevR8zogcDP0qksrX lB17dL/NkHUYdZ9sMivJlBeK1oSMV4BV1fp9TSKQmNasUh6+ESVO3np2yo/9eTw9m9HW wJhnAKVp6kuu+P4KOc0eBwoVjJUiS8JX/TjPlYcAwzO8xUSNb39TFgCcbNoDSz2X/68J xDg8R7hZRiQZEp8e8fEr82Cw9+PnDwP/umG2WcmcjNJc8fm9PevfvLZPYeeV8hWzspWq s/TA== 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 r22-v6si18734471pgm.258.2018.09.18.03.05.00; Tue, 18 Sep 2018 03:05:16 -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 S1729111AbeIRPgg (ORCPT + 99 others); Tue, 18 Sep 2018 11:36:36 -0400 Received: from mail-vs1-f65.google.com ([209.85.217.65]:33816 "EHLO mail-vs1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726838AbeIRPgf (ORCPT ); Tue, 18 Sep 2018 11:36:35 -0400 Received: by mail-vs1-f65.google.com with SMTP id m10-v6so429530vsk.1; Tue, 18 Sep 2018 03:04:44 -0700 (PDT) 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=hSk3B4twbMDvFSuPlrXne9UgVExFWzhUGu+0rETXsn4=; b=l/d0HG9U5kYk0LL7ndxQAVxFcz15uuP+UiQpj8r+es/2MxV4VTU9kmEIENXXBGyHZT Sywt/f78uV6u5cX33cFPPIgSdBDsEX0VRQmjZERZyME/Xd4yZvuDj+hSn1dsGHbPNAo6 MkzOlK+Pd9WVzfrQRhOzzaY4+6qR4QPXImp+3/YStKTeW4VsIQCaq2XiM287vRFk8aqS cKg/Wa7a3I7OqtZwNQDFAFRvEdOdhTbJv/X281nc4cBs+StbJrMJWcpiVbbNbQbdXt4l /P5az2HEu62A3y4IvC7MYpWgAHi+Mp5pUK88Hf814Ar98IIpwQMEqMet8NgSoioLkmQt rZbA== X-Gm-Message-State: APzg51Dz/JExwhefI1PXBDAZdOqoLsaIxfeTxybDMJBveabWWPAdtfll L7L2RTXg59eYn0c8JHEtVCbBE3jDWDmDMcDbab0= X-Received: by 2002:a67:cd07:: with SMTP id u7-v6mr8986255vsl.78.1537265083578; Tue, 18 Sep 2018 03:04:43 -0700 (PDT) MIME-Version: 1.0 References: <1533791723-3882-1-git-send-email-firoz.khan@linaro.org> <1533791723-3882-3-git-send-email-firoz.khan@linaro.org> In-Reply-To: From: Geert Uytterhoeven Date: Tue, 18 Sep 2018 12:04:31 +0200 Message-ID: Subject: Re: [PATCH 2/4] m68k: Replace NR_syscalls macro from asm/unistd.h To: firoz.khan@linaro.org Cc: linux-m68k , y2038 Mailman List , Linux Kernel Mailing List , Linux-Arch , Arnd Bergmann , Deepa Dinamani , marcin.juszkiewicz@linaro.org 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 Firoz, On Tue, Sep 18, 2018 at 9:16 AM Firoz Khan wrote: > On 9 August 2018 at 13:00, Geert Uytterhoeven wrote: > > One first comment below... > > > > On Thu, Aug 9, 2018 at 7:16 AM Firoz Khan wrote: > >> NR_syscalls macro holds the number of system call exist in m68k > >> architecture. This macro is currently the part of asm/unistd.h file. > >> We have to change the value of NR_syscalls, if we add or delete a > >> system call. > >> > >> One of 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. > > > > It can indeed not be part of the UAPI, as UAPI definitions can never change, > > while new syscalls will be added in the future, increasing the number ;-) > > Thanks for your 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_pwritev2 378 > #define __NR_statx 379 > > #ifdef __KERNEL__ > #define __NR_syscalls 380 > #endif > ... > ... #ifdef __KERNEL__ sounds fine to me. Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds