Re: [PATCH 0/3] System call table generation support
From: Paul Burton
Date: Thu Sep 20 2018 - 16:48:44 EST
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 &
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.