On Thu, Nov 29, 2018 at 9:44 AM Firoz Khan firoz.khan@linaro.org wrote:
The system call tables are in different format in all architecture and it will be difficult to manually add, modify or delete the syscall table entries in the res- pective files. To make it easy by keeping a script and which will generate the uapi header and syscall table file. This change will also help to unify the implemen- tation across all architectures.
The system call table generation script is added in kernel/syscalls directory which contain the scripts to generate both uapi header file and system call table files. The syscall.tbl will be input for the scripts.
syscall.tbl contains the list of available system calls along with system call number and corresponding entry point. Add a new system call in this architecture 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. - Compat entry name, if required.
syscallhdr.sh and syscalltbl.sh will generate uapi header unistd_64/n32/o32.h and syscall_table_32_o32/- 64_64/64-n32/64-o32.h files respectively. Both .sh files will parse the content syscall.tbl to generate the header and table files. unistd_64/n32/o32.h will be included by uapi/asm/unistd.h and syscall_table_32_o32/64_64/64-n32- /64-o32.h is included by kernel/syscall_table32_o32/64- _64/64-n32/64-o32.S - the real system call table.
ARM, s390 and x86 architecuture does have similar support. I leverage their implementation to come up with a generic solution.
Signed-off-by: Firoz Khan firoz.khan@linaro.org
Ah, I see you added the syscallnr.sh script from ARM. I guess that is one way to handle it, and the implementation seems fine. It would be good to mention it in the changelog text above though.
Arnd