Hi Arnd,
On Thu, Sep 20, 2018 at 07:52:03AM -0700, Arnd Bergmann wrote:
On Mon, Sep 17, 2018 at 10:17 AM Paul Burton paul.burton@mips.com wrote:
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-syscallsThis looks like a very nice approach that we would probably prefer if we wanted to do it only for mips. The way Firoz did it makes sense in the context of doing it the same way on all architectures, where usually the information is more accessible to human readers by using the number as the primary key.
Yup, I completely agree that moving all this towards being common infrastructure for all architectures is a worthy goal :)
Speaking of nanoMIPS, what is your plan for the syscall ABI there? I can see two ways of approaching it:
a) keep all the MIPSisms in the data structures, and just use a subset of o32 that drops all the obsolete entry points b) start over and stay as close as possible to the generic ABI, using the asm-generic versions of both the syscall table and the uapi header files instead of the traditional version.
We've taken option b in our current downstream kernel & that's what I hope we'll get upstream too. There's no expectation that we'll ever need to mix pre-nanoMIPS & nanoMIPS ISAs or their associated ABIs across the kernel/user boundary so it's felt like a great opportunity to clean up & standardise.
Getting nanoMIPS/p32 support submitted upstream is on my to-do list, but there's a bunch of prep work to get in first & of course that to-do list is forever growing. Hopefully in the next couple of cycles.
Thanks, Paul