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@xxxxxxxx> wrote: > > On Fri, Sep 14, 2018 at 02:08:31PM +0530, Firoz Khan wrote: > > > The purpose of this patch series is: > > > 1. We can easily add/modify/delete system call by changing entry > > > in syscall.tbl file. No need to manually edit many files. > > > > > > 2. 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-syscalls > > This 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
