Date:   Thu, 20 Sep 2018 20:48:37 +0000
From:   Paul Burton <paul.burton@...s.com>
To:     Arnd Bergmann <arnd@...db.de>
CC:     Firoz Khan <firoz.khan@...aro.org>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Rafał Miłecki <zajec5@...il.com>,
        "open list:RALINK MIPS ARCHITECTURE" <linux-mips@...ux-mips.org>,
        Ralf Baechle <ralf@...ux-mips.org>,
        James Hogan <jhogan@...nel.org>,
        gregkh <gregkh@...uxfoundation.org>,
        Philippe Ombredanne <pombredanne@...b.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Kate Stewart <kstewart@...uxfoundation.org>,
        y2038 Mailman List <y2038@...ts.linaro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-arch <linux-arch@...r.kernel.org>,
        Deepa Dinamani <deepa.kernel@...il.com>,
        Marcin Juszkiewicz <marcin.juszkiewicz@...aro.org>
Subject: Re: [PATCH 0/3] System call table generation support

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@...s.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

Powered by blists - more mailing lists