On 6 September 2018 at 21:02, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Tue, Sep 4, 2018 at 6:42 AM Firoz Khan <firoz.khan@xxxxxxxxxx> 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
