From: Arnd Bergmann <arnd@arndb.de>
To: Firoz Khan <firoz.khan@linaro.org>
Cc: Eugene Syromiatnikov <esyr@redhat.com>,
Parisc List <linux-parisc@vger.kernel.org>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Helge Deller <deller@gmx.de>,
Thomas Gleixner <tglx@linutronix.de>,
gregkh <gregkh@linuxfoundation.org>,
Philippe Ombredanne <pombredanne@nexb.com>,
Kate Stewart <kstewart@linuxfoundation.org>,
y2038 Mailman List <y2038@lists.linaro.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
linux-arch <linux-arch@vger.kernel.org>,
Deepa Dinamani <deepa.kernel@gmail.com>,
Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Subject: Re: [PATCH v3 3/6] parisc: add system call table generation support
Date: Tue, 9 Oct 2018 09:47:48 +0200 [thread overview]
Message-ID: <CAK8P3a0D+GUzza--ETrT1NHGduTfFGVoCcSEn5LxvKTtMYisbA@mail.gmail.com> (raw)
In-Reply-To: <CALxhOniJZGNCP+Xw_9EF8hnUEG_AWwrnQ86Gbh7vAW6SrE8ykQ@mail.gmail.com>
On Tue, Oct 9, 2018 at 7:35 AM Firoz Khan <firoz.khan@linaro.org> wrote:
> On Mon, 8 Oct 2018 at 19:27, Arnd Bergmann <arnd@arndb.de> wrote:
> > On Mon, Oct 8, 2018 at 3:02 PM Eugene Syromiatnikov <esyr@redhat.com> wrote:
> > > > > +87 common swapon sys_swapon
> > > > > +88 common reboot sys_reboot
> > > > > +89 common mmap2 sys_mmap2
> > > > > +90 common mmap sys_mmap
> > > > > +91 common munmap sys_munmap
> > > > > +92 common truncate sys_truncate compat_sys_truncate
> > > > > +93 common ftruncate sys_ftruncate compat_sys_ftruncate
> > > > > +94 common fchmod sys_fchmod
> > > > > +95 common fchown sys_fchown
> > > > > +96 common getpriority sys_getpriority
> > > > > +97 common setpriority sys_setpriority
> > > > > +98 common recv sys_recv
> > > > > +99 common statfs sys_statfs compat_sys_statfs
> > > > > +100 common fstatfs sys_fstatfs compat_sys_fstatfs
> > > > > +101 common stat64 sys_stat64
> > >
> > > It is probably worth adding a comment here that syscall 102 was
> > > socketcall, in order to make reason for this jump in syscall numeration
> > > self-evident.
> >
> > +1
> >
> > In general, I'd argue we want to keep all the nontrivial comments that
> > were present in either unistd.h or syscall_table.S.
>
> unistd_32.h, unistd_64.h, syscall_table_32.h, syscall_table_64.h and
> syscall_table_c32.h
> are generated files. unistd.h and syscall_table.S file include
> generated files. I had the
> support to keep the comments in the generated files.
>
> Eg:- from github
> https://github.com/frzkhn/system_call_table_generator/blob/5fe5fb5a3ad457b234e7600d8a4b61b2e3629acd/ia64/syscall.tbl#L105
>
> But I got to know the generated file don't carry any license info and
> comment section. That's
> why I removed it from all architecture.
>
> I'm ok to keep this support for all architecture. Please feel free to
> comment here.
I meant just have the comments in the .tbl file, but not act on them.
One way to do this would be to let the script ignore everything
past the first '#' character in a line by passing it through 'sed -e "s:#.*$::"'
or a similar step (there is probably a nicer way to do this with
shell built-ins).
> > I think this makes more sense, in particular on the other architectures
> > that have different macro names in some cases. When we do this,
> > the entries could get compressed to
> >
> > 108 32 pread64 parisc_pread64
> > 108 64 pread64 sys_pread64
> >
>
> Sure. I can do this thing. The above one may be applicable for parisc not other
> architecture. So the scripts might be slightly different. If we keep a
> standard way,
> the script will be unique. So the only difference will be Makefile and
> .tbl files for all
> architecture; I think that is our one of the goal.
I would expect the above to actually be more important on other
architectures. E.g. on powerpc:
291 32 fstatat64 sys_fstatat64 sys_fstatat64
291 64 newfstatat newfstatat
or (simplified)
291 32 fstatat64 sys_fstatat64
291 64 newfstatat newfstatat
makes much more sense than
291 32 fstatat64 sys_fstatat64
291 64 newfstatat newfstatat sys_fstatat64
Arnd
next prev parent reply other threads:[~2018-10-09 7:47 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-08 5:16 [PATCH v3 0/6] System call table generation support Firoz Khan
2018-10-08 5:16 ` Firoz Khan
2018-10-08 5:16 ` Firoz Khan
2018-10-08 5:16 ` [PATCH v3 1/6] parisc: move __IGNORE* entries to non uapi header Firoz Khan
2018-10-08 5:16 ` [PATCH v3 2/6] parisc: add __NR_Linux_syscalls along with __NR_syscalls Firoz Khan
2018-10-08 5:16 ` [PATCH v3 3/6] parisc: add system call table generation support Firoz Khan
2018-10-08 7:33 ` Firoz Khan
2018-10-08 13:03 ` Eugene Syromiatnikov
2018-10-08 13:56 ` Arnd Bergmann
2018-10-09 5:35 ` Firoz Khan
2018-10-09 5:40 ` Firoz Khan
2018-10-09 7:47 ` Arnd Bergmann [this message]
2018-10-09 9:36 ` Firoz Khan
2018-10-09 11:28 ` Arnd Bergmann
2018-10-09 14:10 ` Firoz Khan
2018-10-08 5:16 ` [PATCH v3 4/6] parisc: uapi header and system call table file generation Firoz Khan
2018-10-08 19:43 ` Helge Deller
2018-10-09 4:56 ` Firoz Khan
2018-10-09 20:13 ` Helge Deller
2018-10-11 6:10 ` Firoz Khan
2018-10-11 6:14 ` Firoz Khan
2018-10-11 6:48 ` Firoz Khan
2018-10-11 7:03 ` Arnd Bergmann
2018-10-11 10:27 ` Helge Deller
2018-10-11 15:01 ` Firoz Khan
2018-10-11 7:07 ` Arnd Bergmann
2018-10-11 8:30 ` Firoz Khan
2018-10-08 5:16 ` [PATCH v3 5/6] parisc: wire up rseq system call Firoz Khan
2018-10-08 5:36 ` Helge Deller
2018-10-08 5:52 ` Firoz Khan
2018-10-08 5:52 ` Firoz Khan
2018-10-08 5:52 ` Firoz Khan
2018-10-08 6:06 ` Helge Deller
2018-10-08 6:48 ` Firoz Khan
2018-10-08 8:23 ` Geert Uytterhoeven
2018-10-08 8:55 ` Firoz Khan
2018-10-08 8:58 ` Geert Uytterhoeven
2018-10-08 9:11 ` Arnd Bergmann
2018-10-08 5:16 ` [PATCH v3 6/6] parisc: syscalls: Ignore nfsservctl for other architectures Firoz Khan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAK8P3a0D+GUzza--ETrT1NHGduTfFGVoCcSEn5LxvKTtMYisbA@mail.gmail.com \
--to=arnd@arndb.de \
--cc=deepa.kernel@gmail.com \
--cc=deller@gmx.de \
--cc=esyr@redhat.com \
--cc=firoz.khan@linaro.org \
--cc=gregkh@linuxfoundation.org \
--cc=jejb@parisc-linux.org \
--cc=kstewart@linuxfoundation.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=marcin.juszkiewicz@linaro.org \
--cc=pombredanne@nexb.com \
--cc=tglx@linutronix.de \
--cc=y2038@lists.linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.