On 17 September 2018 at 22:47, Paul Burton paul.burton@mips.com wrote:
Hi Firoz,
On Fri, Sep 14, 2018 at 02:08:31PM +0530, Firoz Khan wrote:
The purpose of this patch series is:
- We can easily add/modify/delete system call by changing entry
in syscall.tbl file. No need to manually edit many files.
- It is easy to unify the system call implementation across all
the architectures.
The system call tables are in different format in all architecture and it will be difficult to manually add or modify the system calls in the respective files manually. To make it easy by keeping a script and which'll generate the header file and syscall table file so this change will unify them across all architectures.
Interesting :)
I actually started on something similar recently with the goals of reducing the need to adjust both asm/unistd.h & the syscall entry tables when adding syscalls, clean up asm/unistd.h a bit & make it easier/cleaner to add support for nanoMIPS & the P32 ABI.
My branch still needed some work but it's here if you're interested:
git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git wip-mips-syscalls https://git.kernel.org/pub/scm/linux/kernel/git/mips/linux.git/log/?h=wip-mips-syscallsThere are some differences:
I'd placed syscall numbers the 3 current MIPS ABIs in one table, rather than splitting it up. I can see pros & cons to both though so I'm not tied to having a single all-encompassing table.
I'd mostly inferred the entry point names from the syscall names, only specifying them where they differ. Again I'm not particularly tied to this.
I'd made asm/unistd.h behave like asm-generic/unistd.h with the __SYSCALL() macro, where you generate separate syscall_table_* headers. I'm fine with that too.
So I'm pretty happy to go with your series, though I agree with Arnd on the ABI/file naming & the missing syscalls that were added in the 4.18 cycle. We probably need to provide mipsmt_sys_sched_[gs]etaffinity as aliases to sys_sched_[gs]etaffinity when CONFIG_MIPS_MT_FPAFF isn't enabled in order to fix the issue the kbuild test robot reported.
But I'm looking forward to v2 :)
Thanks, Paul
Thanks for your comments :)
We're planning to come up with a generic script for system call table generation across all the architecture. So certain things I have to keep same across all the architecture.
Having a single script is always our plan for long run. But I have to keep a separate versions for the start so each architecture can be handled in one series. Which would make easier to merge in the initial version.
we could probably add it to scripts/*.sh first, but that requires more coordination between the architectures.
- Firoz