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