From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw1-f66.google.com ([209.85.161.66]:43172 "EHLO mail-yw1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727846AbeIRRJ2 (ORCPT ); Tue, 18 Sep 2018 13:09:28 -0400 Received: by mail-yw1-f66.google.com with SMTP id l189-v6so612516ywb.10 for ; Tue, 18 Sep 2018 04:37:17 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <1536036087-15260-1-git-send-email-firoz.khan@linaro.org> <1536036087-15260-4-git-send-email-firoz.khan@linaro.org> From: Firoz Khan Date: Tue, 18 Sep 2018 17:07:16 +0530 Message-ID: Subject: Re: [PATCH 3/4] sparc: Add system call table generation support Content-Type: text/plain; charset="UTF-8" Sender: linux-arch-owner@vger.kernel.org List-ID: To: Arnd Bergmann Cc: David Miller , sparclinux , gregkh , Philippe Ombredanne , Thomas Gleixner , Kate Stewart , y2038 Mailman List , Linux Kernel Mailing List , linux-arch , Deepa Dinamani , Marcin Juszkiewicz Message-ID: <20180918113716.anWLYK9ZYpvvxuRCZgS4nV4wPcbXrfvzZ_c_NfOepMc@z> On 6 September 2018 at 21:02, Arnd Bergmann wrote: > On Tue, Sep 4, 2018 at 6:42 AM Firoz Khan wrote: > >> The system call table generation script is added in >> syscalls directory which contain the script to generate >> both uapi header file system call table generation file >> and syscall_32/64.tbl file which'll be the input for the >> scripts. > > I would argue that for sparc we only want a single input > table, since the 32/64 versions are similar enough that the > differences can be addressed with 'abi' flag, rather than > having everything marked as 'common'. Isn't that the > purpose of the abi flag in the first place? > > Arnd Yes, we can do that way also. But few concerns I would like to share with you. I feel it add the complexity in the scripts. eg:- 108 32 setresuid32 sys_setresuid 108 64 setresuid sys_setresuid This case the script has to be smart enough to parse the .tbl file properly. It need more logic in the scripts. This is not common. So if you keep separate .tbl we can avoid this. ABI flag is serving *nothing* in all other architecture including SPARC. But as I told in the cover letter, I followed x86/arm/ s390 architecture's system table generation implementation. They are keeping ABI flag. In our case we can delete this flag completely from all architectures. Most of the architecture these 32/64 similarity is absent. So it would be better keep separate files to maintain a generic script across all architecture. One question here is; while invoking the script I'm passing the abi flag. It is simply keeping in the .tbl file to make the file similar to x86. What I can do here? - Firoz