mbox series

[0/3] System call table generation support

Message ID 1536914314-5026-1-git-send-email-firoz.khan@linaro.org
Headers show
Series System call table generation support | expand

Message

Firoz Khan Sept. 14, 2018, 8:38 a.m. UTC
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.

syscall.tbl contains the list of available system calls along with 
system call number and corresponding entry point. Add a new system 
call in this architecture will be possible by adding new entry in 
the syscall.tbl file.

Adding a new table entry consisting of:
        - System call number.
        - ABI.
        - System call name.
        - Entry point name.
        - Compat entry name, if required.

ARM, s390 and x86 architecuture does exist the similar support. I 
leverage their implementation to come up with a generic solution.

I have done the same support for work for alpha, m68k, microblaze, 
ia64, powerpc, parisc, sh, sparc, and xtensa. But I started sending 
the patch for one architecuture for review. Below mentioned git
repository contains more details.
Git repo:- https://github.com/frzkhn/system_call_table_generator/

Finally, this is the ground work for solving the Y2038 issue. We 
need to add/change two dozen of system calls to solve Y2038 issue. 
So this patch series will help to easily modify from existing 
system call to Y2038 compatible system calls.

I started working system call table generation on 4.17-rc1. I used 
marcin's script - https://github.com/hrw/syscalls-table to generate 
the syscall.tbl file. And this will be the input to the system call 
table generation script. But there are couple system call got add 
in the latest rc release. If run Marcin's script on latest release,
It will generate a new syscall.tbl. But I still use the old file - 
syscall.tbl and once all review got over I'll update syscall.tbl 
alone w.r.to the tip of the kernel. The impact of this thing, few 
of the system call won't work. 

Firoz Khan (3):
  mips: Add __NR_syscalls macro in uapi/asm/unistd.h
  mips: Add system call table generation support
  mips: uapi header and system call table file generation

 arch/mips/Makefile                        |    3 +
 arch/mips/include/asm/Kbuild              |    4 +
 arch/mips/include/uapi/asm/Kbuild         |    3 +
 arch/mips/include/uapi/asm/unistd.h       | 1053 +----------------------------
 arch/mips/kernel/scall32-o32.S            |  385 +----------
 arch/mips/kernel/scall64-64.S             |  334 +--------
 arch/mips/kernel/scall64-n32.S            |  337 +--------
 arch/mips/kernel/scall64-o32.S            |  374 +---------
 arch/mips/kernel/syscall_table_32_o32.S   |    8 +
 arch/mips/kernel/syscall_table_64_64.S    |    9 +
 arch/mips/kernel/syscall_table_64_n32.S   |    8 +
 arch/mips/kernel/syscall_table_64_o32.S   |    9 +
 arch/mips/kernel/syscalls/Makefile        |   62 ++
 arch/mips/kernel/syscalls/README.md       |   16 +
 arch/mips/kernel/syscalls/syscall_32.tbl  |  375 ++++++++++
 arch/mips/kernel/syscalls/syscall_64.tbl  |  335 +++++++++
 arch/mips/kernel/syscalls/syscall_n32.tbl |  339 ++++++++++
 arch/mips/kernel/syscalls/syscallhdr.sh   |   37 +
 arch/mips/kernel/syscalls/syscalltbl.sh   |   44 ++
 19 files changed, 1268 insertions(+), 2467 deletions(-)
 create mode 100644 arch/mips/kernel/syscall_table_32_o32.S
 create mode 100644 arch/mips/kernel/syscall_table_64_64.S
 create mode 100644 arch/mips/kernel/syscall_table_64_n32.S
 create mode 100644 arch/mips/kernel/syscall_table_64_o32.S
 create mode 100644 arch/mips/kernel/syscalls/Makefile
 create mode 100644 arch/mips/kernel/syscalls/README.md
 create mode 100644 arch/mips/kernel/syscalls/syscall_32.tbl
 create mode 100644 arch/mips/kernel/syscalls/syscall_64.tbl
 create mode 100644 arch/mips/kernel/syscalls/syscall_n32.tbl
 create mode 100644 arch/mips/kernel/syscalls/syscallhdr.sh
 create mode 100644 arch/mips/kernel/syscalls/syscalltbl.sh

-- 
1.9.1

Comments

Paul Burton Sept. 17, 2018, 5:17 p.m. UTC | #1
Hi Firoz,

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

There are some differences:

  - I'd placed syscall numbers the 3 current MIPS ABIs in one table,
    rather than splitting it up. I can see pros & cons to both though so
    I'm not tied to having a single all-encompassing table.

  - I'd mostly inferred the entry point names from the syscall names,
    only specifying them where they differ. Again I'm not particularly
    tied to this.

  - I'd made asm/unistd.h behave like asm-generic/unistd.h with the
    __SYSCALL() macro, where you generate separate syscall_table_*
    headers. I'm fine with that too.

So I'm pretty happy to go with your series, though I agree with Arnd on
the ABI/file naming & the missing syscalls that were added in the 4.18
cycle. We probably need to provide mipsmt_sys_sched_[gs]etaffinity as
aliases to sys_sched_[gs]etaffinity when CONFIG_MIPS_MT_FPAFF isn't
enabled in order to fix the issue the kbuild test robot reported.

But I'm looking forward to v2 :)

Thanks,
    Paul
Firoz Khan Sept. 18, 2018, 2:13 p.m. UTC | #2
On 17 September 2018 at 22:47, Paul Burton <paul.burton@mips.com> wrote:
> Hi Firoz,

>

> 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

>

> There are some differences:

>

>   - I'd placed syscall numbers the 3 current MIPS ABIs in one table,

>     rather than splitting it up. I can see pros & cons to both though so

>     I'm not tied to having a single all-encompassing table.

>

>   - I'd mostly inferred the entry point names from the syscall names,

>     only specifying them where they differ. Again I'm not particularly

>     tied to this.

>

>   - I'd made asm/unistd.h behave like asm-generic/unistd.h with the

>     __SYSCALL() macro, where you generate separate syscall_table_*

>     headers. I'm fine with that too.

>

> So I'm pretty happy to go with your series, though I agree with Arnd on

> the ABI/file naming & the missing syscalls that were added in the 4.18

> cycle. We probably need to provide mipsmt_sys_sched_[gs]etaffinity as

> aliases to sys_sched_[gs]etaffinity when CONFIG_MIPS_MT_FPAFF isn't

> enabled in order to fix the issue the kbuild test robot reported.

>

> But I'm looking forward to v2 :)

>

> Thanks,

>     Paul


Thanks for your comments :)

We're planning to come up with a generic script for system call table
generation across all the architecture. So certain things I have to keep
same across  all the architecture.

Having a single script is always our plan for long run. But I have to keep a
separate versions for the start so each architecture can be handled  in one
series. Which would make easier to merge in the initial version.

we could probably add it to scripts/*.sh first, but that requires more
coordination between the architectures.

- Firoz
Arnd Bergmann Sept. 20, 2018, 2:52 p.m. UTC | #3
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.

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.

         Arnd

         Arnd
Paul Burton Sept. 20, 2018, 8:48 p.m. UTC | #4
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
Christoph Hellwig Sept. 21, 2018, 6:09 a.m. UTC | #5
On Thu, Sep 20, 2018 at 08:48:37PM +0000, Paul Burton wrote:
> > 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.


p32 is just the ABI name for nanoMIPS or yet another MIPS ABI?

Either way, І think if there is yet another ABI even on an existing port
we should always aim for the asm-generic syscall table indeed.

Especially for mips where o32 has a rather awkward ABI only explained by
odd decisions more than 20 years ago.
Paul Burton Sept. 21, 2018, 7:32 p.m. UTC | #6
Hi Christoph,

On Thu, Sep 20, 2018 at 11:09:41PM -0700, Christoph Hellwig wrote:
> On Thu, Sep 20, 2018 at 08:48:37PM +0000, Paul Burton wrote:

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

> 

> p32 is just the ABI name for nanoMIPS or yet another MIPS ABI?


p32 is the ABI for nanoMIPS - ie. it is a new ABI, but it's not for use
with pre-nanoMIPS ISAs & nanoMIPS isn't used with o32/n32/n64.

Some of the code density improvements nanoMIPS brings are due to the ISA
& p32 ABI being developed together - eg. the load/store multiple &
save/restore instructions make it easy to save sequences of $sp, $fp,
$ra & some number of the $sN callee-saved registers. Compressed register
number encodings generally include registers that make sense for the p32
ABI, and I'm sure there were other things I've forgotten.

> Either way, І think if there is yet another ABI even on an existing port

> we should always aim for the asm-generic syscall table indeed.

> 

> Especially for mips where o32 has a rather awkward ABI only explained by

> odd decisions more than 20 years ago.


Glad to hear we're on the same page :)

I'm all for being less "special" & couldn't care less if our nanoMIPS
support isn't compatible with IRIX.

Thanks,
    Paul