mbox series

[v2,0/5] alpha: system call table generation support

Message ID 1541079817-3431-1-git-send-email-firoz.khan@linaro.org
Headers show
Series alpha: system call table generation support | expand

Message

Firoz Khan Nov. 1, 2018, 1:43 p.m. UTC
The purpose of this patch series is, we can easily
add/modify/delete system call table support by cha-
nging entry in syscall.tbl file instead of manually
changing many files. The other goal is to unify the 
system call table generation support implementation 
across all the architectures. 

The system call tables are in different format in 
all architecture. It will be difficult to manually
add, modify or delete the system calls in the resp-
ective files manually. To make it easy by keeping a 
script and which'll generate uapi header file and 
syscall table file.

syscall.tbl contains the list of available system 
calls along with system call number and correspond-
ing entry point. Add a new system call in this arch-
itecture 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.

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

I have done the same support for work for ia64, m68k, 
microblaze, mips, parisc, powerpc, sh sparc and xtensa.
Below mentioned git repository contains more details 
about the workflow.

 https://github.com/frzkhn/system_call_table_generator/

Finally, this is the ground work to solve the Y2038
issue. We need to add two dozen of system calls to solve
Y2038 issue. So this patch series will help to add new 
system calls easily by adding new entry in the syscall.tbl.

Changes since v1:
 - optimized/updated the syscall table generation 
   scripts.
 - fixed all mixed indentation issues in syscall.tbl.
 - added "comments" in syscall.tbl.

Firoz Khan (5):
  alpha: move __IGNORE* entries to non uapi header
  alpha: remove CONFIG_OSF4_COMPAT flag from syscall table
  alpha: add __NR_syscalls along with NR_SYSCALLS
  alpha: add system call table generation support
  alpha: generate uapi header and syscall table header files

 arch/alpha/Makefile                      |   3 +
 arch/alpha/include/asm/Kbuild            |   2 +-
 arch/alpha/include/asm/unistd.h          |  23 +-
 arch/alpha/include/uapi/asm/Kbuild       |   1 +
 arch/alpha/include/uapi/asm/unistd.h     | 484 +--------------------------
 arch/alpha/kernel/osf_sys.c              |   9 +-
 arch/alpha/kernel/syscalls/Makefile      |  38 +++
 arch/alpha/kernel/syscalls/syscall.tbl   | 453 ++++++++++++++++++++++++++
 arch/alpha/kernel/syscalls/syscallhdr.sh |  36 ++
 arch/alpha/kernel/syscalls/syscalltbl.sh |  36 ++
 arch/alpha/kernel/systbls.S              | 542 +------------------------------
 11 files changed, 600 insertions(+), 1027 deletions(-)
 create mode 100644 arch/alpha/kernel/syscalls/Makefile
 create mode 100644 arch/alpha/kernel/syscalls/syscall.tbl
 create mode 100644 arch/alpha/kernel/syscalls/syscallhdr.sh
 create mode 100644 arch/alpha/kernel/syscalls/syscalltbl.sh

-- 
1.9.1

Comments

Matt Turner Nov. 5, 2018, 9:31 p.m. UTC | #1
On Thu, Nov 1, 2018 at 6:44 AM Firoz Khan <firoz.khan@linaro.org> wrote:
>

> The purpose of this patch series is, we can easily

> add/modify/delete system call table support by cha-

> nging entry in syscall.tbl file instead of manually

> changing many files. The other goal is to unify the

> system call table generation support implementation

> across all the architectures.

>

> The system call tables are in different format in

> all architecture. It will be difficult to manually

> add, modify or delete the system calls in the resp-

> ective files manually. To make it easy by keeping a

> script and which'll generate uapi header file and

> syscall table file.

>

> syscall.tbl contains the list of available system

> calls along with system call number and correspond-

> ing entry point. Add a new system call in this arch-

> itecture will be possible by adding new entry in the

> syscall.tbl file.


Sounds like a worthy goal.

I tried applying the patches and it seems they haven't been rebased
since v4.18. My rebases are in
https://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git/log/?h=for-linus

They seem to work for me, FWIW.

Is your plan to have the patches go through the separate architecture
trees, or go in together? I think I'd at least prefer for another
architecture to take the plunge before alpha.
Firoz Khan Nov. 6, 2018, 4:12 a.m. UTC | #2
Hi Matt,

On Tue, 6 Nov 2018 at 03:01, Matt Turner <mattst88@gmail.com> wrote:
>

> On Thu, Nov 1, 2018 at 6:44 AM Firoz Khan <firoz.khan@linaro.org> wrote:

> >

> > The purpose of this patch series is, we can easily

> > add/modify/delete system call table support by cha-

> > nging entry in syscall.tbl file instead of manually

> > changing many files. The other goal is to unify the

> > system call table generation support implementation

> > across all the architectures.

> >

> > The system call tables are in different format in

> > all architecture. It will be difficult to manually

> > add, modify or delete the system calls in the resp-

> > ective files manually. To make it easy by keeping a

> > script and which'll generate uapi header file and

> > syscall table file.

> >

> > syscall.tbl contains the list of available system

> > calls along with system call number and correspond-

> > ing entry point. Add a new system call in this arch-

> > itecture will be possible by adding new entry in the

> > syscall.tbl file.

>

> Sounds like a worthy goal.


Thanks! This is Arnd's idea to come up with a common script
for all the architecture. This implementation is a groundwork to
solve Y2038 issue.

>

> I tried applying the patches and it seems they haven't been rebased

> since v4.18. My rebases are in

> https://git.kernel.org/pub/scm/linux/kernel/git/mattst88/alpha.git/log/?h=for-linus


I was rebased with 4.19-rc8 before sending v2 (what I remember).

>

> They seem to work for me, FWIW.

>

> Is your plan to have the patches go through the separate architecture

> trees, or go in together? I think I'd at least prefer for another

> architecture to take the plunge before alpha.


I would like Arnd's to comment on this as it is my first patch series. As I
mentioned in the cover letter this implementation done for 8 architecture-
alpha, ia64, m68k, microblaze, parisc, sh, sparc, and xtensa. Most of the
review are also done. mips and powerpc are *almost* completed. FYI,
The system call table generation script for IA64 merged in linux-next.

Firoz