Re: [PATCH 0/3] System call table generation support

[Paul Burton <paul.burton@mips.com>]

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:
> > > 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