[LTP] [PATCH 0/4] Automatically generate syscalls.h

Jan Stancek jstancek@redhat.com
Thu Sep 26 09:47:35 CEST 2024


On Thu, Sep 26, 2024 at 9:07 AM Andrea Cervesato
<andrea.cervesato@suse.com> wrote:
>
>
> On 9/25/24 22:01, Jan Stancek wrote:
> > On Tue, Sep 24, 2024 at 3:24 PM Andrea Cervesato
> > <andrea.cervesato@suse.com> wrote:
> >>
> >> On 9/24/24 15:16, Jan Stancek wrote:
> >>> On Tue, Sep 24, 2024 at 10:46 AM Andrea Cervesato via ltp
> >>> <ltp@lists.linux.it> wrote:
> >>>> Hi!
> >>>>
> >>>> Please consider this patchset as a draft open for discussion.
> >>> Have you compared old and new defines? Are there any differences
> >>> (other than additions)?
> >>>
> >> Only additions, but this is a draft work and I'm searching for
> >> alternative ideas as well.
> >> For example, the limitation of this approach is that syscalls.h has to
> >> be generated anyway.
> > I guess it wouldn't be too difficult to change script to generate .in
> > files instead, right?
> I'm already doing it in the generate_syscalls.sh script, so it's quite
> easy. The point is if we want to make this extra step, because maybe we
> can just download the tables already created by the syscalls-table
> project and we have .in files for free. But that approach has downsides
> of course.
> >> At the same time, we have projects like
> >> https://github.com/hrw/syscalls-table (that inspired my script)
> >> providing python bindings and *maybe* it could be used to create a
> >> python script which generate .in files when they need to be updated.
> > python feels like an extra step, since we could do it in existing shell script.
> > Maybe store a copy of update-tables.sh in LTP repo, and add some wrapper
> > to provide create_tables_for_LTP() function and a check to print warning if
> > original github project changes update-tables.sh.
> >
> > create_tables_for_LTP() would generate .in files and rest can stay as it is.
>
> I was also thinking that maybe it's enough to have 2 scripts: one for
> updating syscalls .in files when needed and one for merging them.
>
> The only problem I see in this approach is: when do we want to update
> tables? It would be nice to do that every ./configure , but that would
> be too much because of git/curl dependency.

LTP can run in labs with no external network access, so I'd avoid any download
as part of configure. And in unlikely case github project disappears
we would have
LTP releases out there with broken configure.

Looking at git log, in last couple years we updated syscalls maybe 3-4
times each year.
I think it's enough to have it as an extra step when we need to update syscalls.
I see it as a helper script you run to patch .in files. Even if that
uses readily available
tables from github project, it would still be a patch that people can
review and spot
potential issues (originating from script or tables).

>
> >> Etc..
> >>
> >>>> Andrea
> >>>>
> >>>> On 9/24/24 10:06, Andrea Cervesato wrote:
> >>>>> The problem we have at the moment is that all syscalls input files must
> >>>>> be changed by hand each time we need to test a new syscall. The idea is
> >>>>> to simplify this process, providing a script that is able to read from
> >>>>> kernel sources and to generate all syscalls files we need.
> >>>>>
> >>>>> This is done by the generate_syscalls.sh script that can be used as
> >>>>> following:
> >>>>>
> >>>>> ./generate_syscalls.sh path/to/kernel/source path/to/syscalls.h
> >>>>>
> >>>>> This approach requires a certain type of attention, due to the fact that
> >>>>> we need to generate syscalls.h at each kernel version, or when new
> >>>>> syscalls have been added in the kernel.
> >>>>>
> >>>>> Signed-off-by: Andrea Cervesato <andrea.cervesato@suse.com>
> >>>>> ---
> >>>>> Andrea Cervesato (4):
> >>>>>          Rename syscalls order file to supported-arch.txt
> >>>>>          Add script to generate syscalls.h
> >>>>>          Deprecate old syscalls input files
> >>>>>          Save syscalls.h inside repo
> >>>>>
> >>>>>     include/lapi/.gitignore                            |     1 -
> >>>>>     include/lapi/syscalls.h                            | 34272 +++++++++++++++++++
> >>>>>     include/lapi/syscalls/aarch64.in                   |   306 -
> >>>>>     include/lapi/syscalls/arc.in                       |   325 -
> >>>>>     include/lapi/syscalls/arm.in                       |   404 -
> >>>>>     include/lapi/syscalls/blacklist-syscalls.txt       |     6 +
> >>>>>     include/lapi/syscalls/generate_syscalls.sh         |   292 +
> >>>>>     include/lapi/syscalls/hppa.in                      |    52 -
> >>>>>     include/lapi/syscalls/i386.in                      |   439 -
> >>>>>     include/lapi/syscalls/ia64.in                      |   956 +-
> >>>>>     include/lapi/syscalls/loongarch.in                 |   310 -
> >>>>>     include/lapi/syscalls/mips_n32.in                  |   379 -
> >>>>>     include/lapi/syscalls/mips_n64.in                  |   355 -
> >>>>>     include/lapi/syscalls/mips_o32.in                  |   425 -
> >>>>>     include/lapi/syscalls/powerpc.in                   |   432 -
> >>>>>     include/lapi/syscalls/powerpc64.in                 |   432 -
> >>>>>     include/lapi/syscalls/regen.sh                     |   129 -
> >>>>>     include/lapi/syscalls/s390.in                      |   419 -
> >>>>>     include/lapi/syscalls/s390x.in                     |   367 -
> >>>>>     include/lapi/syscalls/sh.in                        |   413 -
> >>>>>     include/lapi/syscalls/sparc.in                     |   418 -
> >>>>>     include/lapi/syscalls/sparc64.in                   |   383 -
> >>>>>     include/lapi/syscalls/strip_syscall.awk            |    19 -
> >>>>>     .../lapi/syscalls/{order => supported-arch.txt}    |     1 -
> >>>>>     include/lapi/syscalls/x86_64.in                    |   396 -
> >>>>>     25 files changed, 35174 insertions(+), 6757 deletions(-)
> >>>>> ---
> >>>>> base-commit: 968e6245d93bc91723e72086a71e6bc50f495d0b
> >>>>> change-id: 20240923-generate_syscalls-780dc2227bdb
> >>>>>
> >>>>> Best regards,
> >>>> --
> >>>> Mailing list info: https://lists.linux.it/listinfo/ltp
> >>>>
>



More information about the ltp mailing list