Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2317361imu; Sun, 18 Nov 2018 21:22:00 -0800 (PST) X-Google-Smtp-Source: AJdET5c245YV6h4NYOgIzW1rHyNIyem6eEsecE41GGW6zHvzx/kVV6lflhgW+elBeAMJZQhqzWdW X-Received: by 2002:a63:6205:: with SMTP id w5mr18908108pgb.53.1542604920923; Sun, 18 Nov 2018 21:22:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542604920; cv=none; d=google.com; s=arc-20160816; b=IR8OzU49fBIlq/R7f+L2YfIWkcqGAxW1Cxa4Oni5Bn3fA1hD6mCq9Y67eOsw7dFB39 UQonugQDv0msdAcBGZxA4wjwi4Z4FUF64YxKwH/Z+qB14lYZIa0HjpkQObXTRbvtDCuo qjthOuy6Alb7ZhACd4blDwKHqOWa/t5su0cjhTPUbmGeArMEnib6zOHYZl2xg7eT7rnM BHKvaeH+H9b+vUja5Nc+3QvGQNwP3CuFEWm06rf64y1U/Qoh/Th41NOerZ6VEl7SEYNd WRtxOX+Jip1jxeRKQn2PsrlIYyy3SIXKkE7RD0mrZ1Rm3BCxAa8B8Wuk3XjazyekJU7D ihmg== 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=ONgEdGayxNnyo0orD42muf3UoIznewYIaD9QLvpQwB8=; b=jMVbHzJfUeCKGnXs6zPYMY7gmfqYlL+vrGkLkRvah9t+IZCaFLKJE97B9N8pmF/SoP 8Up72a2dqttnLhB+MAYxkpB8SBZ/SCYfAFsITN57CT5QYpUYyNaOc0xc5NquCkrf6seS 22ZQhMAM4pbmHzZTdzEGqfwXZEJ4tnOuqk9qt8yrd8meI/BWabidCxcqAX+dcKnp6kP5 356S6tB+D+w/reOW9Hn4gNHcGwihb3jyyILwvCg2yUlJAYa0Bn3BEtczWX7lA3OQrZJA n/oBpW5Bh/B4Y1j7BOmAw/7QW6/9C078fSR3XGJ4GcCx88A8obtgMdpgp/ivemq6ZT5T KU5w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=D5MpCRrR; 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 n6-v6si39331861pla.245.2018.11.18.21.21.45; Sun, 18 Nov 2018 21:22:00 -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=D5MpCRrR; 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 S1726011AbeKSPnk (ORCPT + 99 others); Mon, 19 Nov 2018 10:43:40 -0500 Received: from mail-it1-f193.google.com ([209.85.166.193]:38355 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725903AbeKSPnj (ORCPT ); Mon, 19 Nov 2018 10:43:39 -0500 Received: by mail-it1-f193.google.com with SMTP id h65so2463786ith.3 for ; Sun, 18 Nov 2018 21:21:10 -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=ONgEdGayxNnyo0orD42muf3UoIznewYIaD9QLvpQwB8=; b=D5MpCRrRCju8vSIPkQwuLYybswQjUWlxpBr+xanrLwSzlU1KgR4pb2lWLjRzeXzm0I fdidIDY2zD1lN71Jj8I7NZoWgamlHW7iQObGsejkb+oc0/TkNwzq5oomdxf7IuGj1r2Q isez5gEY3v6wBA7FY3waCIUVGAAtDAmfIvNyM= 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=ONgEdGayxNnyo0orD42muf3UoIznewYIaD9QLvpQwB8=; b=IbjfgbTGTfSEeXR/7ZHmwMS8eJ6F1cDxu3Zc2rro924oSKaTZTt8XKVxPQ9Q+Qd+uV bxu99QaH9yxpc4fuW/fu4MVfOIGTYjUR40ctNN/ypw532RVJHOH3sWofwtSaCXdw2MGC /EGhVLS/r3DO9uMJjo2czN7foSE5l/TnneOm5Qk8dKNr916mYILamj7U4FVhCq01RdjZ 1kiYlHis4EKc6MLKVdfjovXAIr5giCD76e+fgIFxpXIdPDSmfdXyrp9P0oFnXd+JW+hG YwszUflUeHAODtBsM6iIJD5kNToKC+5y+8hQGdrIep3mqg1lSCbAjPEin4iGq7wlWrWO k/kw== X-Gm-Message-State: AGRZ1gKKWcae+sbZ5SSh0QKdjd6QpW6DRZEv6KuuBOkFBF4YsTj2dM6P +i4/0T1CucqGIs4c4Eg5M2d5+DTci55+4pVeEvS7vA== X-Received: by 2002:a24:b009:: with SMTP id d9-v6mr6609355itf.166.1542604869910; Sun, 18 Nov 2018 21:21:09 -0800 (PST) MIME-Version: 1.0 References: <1542177301-25844-1-git-send-email-firoz.khan@linaro.org> <58c3c4a4-7f55-bf08-1c96-ef1aa7f97072@gmx.de> <20181116215502.GA6585@ls3530.dellerweb.de> <20181117162623.GA14763@ls3530.dellerweb.de> In-Reply-To: <20181117162623.GA14763@ls3530.dellerweb.de> From: Firoz Khan Date: Mon, 19 Nov 2018 10:51:00 +0530 Message-ID: Subject: Re: [PATCH v7 0/5] parisc: system call table generation support To: Helge Deller Cc: Arnd Bergmann , linux-parisc@vger.kernel.org, James.Bottomley@hansenpartnership.com, dave.anglin@bell.net, "James E . J . Bottomley" , Thomas Gleixner , Greg Kroah-Hartman , Philippe Ombredanne , 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 Helge, On Sat, 17 Nov 2018 at 22:01, Helge Deller wrote: > > * Arnd Bergmann : > > On Fri, Nov 16, 2018 at 1:55 PM Helge Deller wrote: > > > > On Fri, 16 Nov 2018 at 01:01, Helge Deller wrote: > > > > > > > > > > On 14.11.2018 07:34, Firoz Khan wrote: > > > > > > The purpose of this patch series is, we can easily > > > > > > add/modify/delete system call table support by cha- > > > > > > nging entry in syscall.tbl file instead of manually > > > > > > changing many files. The other goal is to unify the > > > > > > system call table generation support implementation > > > > > > across all the architectures. > > > > > > > > > > > > The system call tables are in different format in > > > > > > all architecture. It will be difficult to manually > > > > > > add, modify or delete the system calls in the resp- > > > > > > ective files manually. To make it easy by keeping a > > > > > > script and which'll generate uapi header file and > > > > > > syscall table file. > > > > > > > > > > > > syscall.tbl contains the list of available system > > > > > > calls along with system call number and correspond- > > > > > > ing entry point. Add a new system call in this arch- > > > > > > itecture will be possible by adding new entry in the > > > > > > syscall.tbl file. > > > > > > > > > > > > Adding a new table entry consisting of: > > > > > > - System call number. > > > > > > - ABI. > > > > > > - System call name. > > > > > > - Entry point name. > > > > > > > > > > > > .... > > > > > > Firoz Khan (5): > > > > > > parisc: move __IGNORE* entries to non uapi header > > > > > > parisc: add __NR_syscalls along with __NR_Linux_syscalls > > > > > > parisc: add system call table generation support > > > > > > parisc: generate uapi header and system call table files > > > > > > parisc: syscalls: ignore nfsservctl for other architectures > > > > > > > > > > Firoz, you may add > > > > > Acked-by: Helge Deller > > > > > to the whole parisc series. > > > > > > > > Sure, will do. > > > > I'm on a vacation right now. will send mid next week. > > > > > > That's ok, there is no urgency. > > > > > > Actually, I noticed that the generated files unistd_32.h > > > and unistd_64.h do have the same contents, since on parisc > > > we keep the syscall numbers the same for 32- and 64-bit. > > > With that in mind, we can simply generate on unistd.h > > > file for both variants. > > > > It depends on what we want to do in the future. When we add > > around 20 new system calls fro y2038, my plan was to > > only add them for 32-bit architectures, leaving holes on > > 64-bit ones. > > Ok, I didn't thought of that. > > > We can also assign the new numbers on parisc64 but they would have the > > same entry point as existing calls. > > > If you prefer doing it like that, your patch seems fine for that, > > it's just slightly inconsistent with the other 64-bit architectures > > then. > > I really prefer to stay in sync with other major architectures. > So, please drop my last patch. > > Instead please apply only the next one, which drops the NR_Linux > offset value (which is 0 anyway). This can be easily done. FYI, our intention is the generated file must be same as the old one. That's why I kept the offset as it is. I can add one extra patch to remove NR_Linux. > > Thanks, > Helge > > > diff --git a/arch/parisc/include/uapi/asm/unistd.h b/arch/parisc/include/uapi/asm/unistd.h > index 6e31f58ad6b5..98dc953656af 100644 > --- a/arch/parisc/include/uapi/asm/unistd.h > +++ b/arch/parisc/include/uapi/asm/unistd.h > @@ -2,7 +2,6 @@ > #ifndef _UAPI_ASM_PARISC_UNISTD_H_ > #define _UAPI_ASM_PARISC_UNISTD_H_ > > -#define __NR_Linux 0 > #ifdef __LP64__ > #include > #else > diff --git a/arch/parisc/kernel/syscalls/Makefile b/arch/parisc/kernel/syscalls/Makefile > index defa8878f6d2..4dcc5c9ae7f2 100644 > --- a/arch/parisc/kernel/syscalls/Makefile > +++ b/arch/parisc/kernel/syscalls/Makefile > @@ -12,22 +12,18 @@ systbl := $(srctree)/$(src)/syscalltbl.sh > quiet_cmd_syshdr = SYSHDR $@ > cmd_syshdr = $(CONFIG_SHELL) '$(syshdr)' '$<' '$@' \ > '$(syshdr_abis_$(basetarget))' \ > - '$(syshdr_pfx_$(basetarget))' \ > - '$(syshdr_offset_$(basetarget))' > + '$(syshdr_pfx_$(basetarget))' > > quiet_cmd_systbl = SYSTBL $@ > cmd_systbl = $(CONFIG_SHELL) '$(systbl)' '$<' '$@' \ > '$(systbl_abis_$(basetarget))' \ > - '$(systbl_abi_$(basetarget))' \ > - '$(systbl_offset_$(basetarget))' > + '$(systbl_abi_$(basetarget))' > > syshdr_abis_unistd_32 := common,32 > -syshdr_offset_unistd_32 := __NR_Linux I'll remove this line > $(uapi)/unistd_32.h: $(syscall) $(syshdr) > $(call if_changed,syshdr) > > syshdr_abis_unistd_64 := common,64 > -syshdr_offset_unistd_64 := __NR_Linux And this one too. rest of the files will be the same w.r.t v7. Thanks Firoz > $(uapi)/unistd_64.h: $(syscall) $(syshdr) > $(call if_changed,syshdr) >