All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Firoz Khan <firoz.khan@linaro.org>
Cc: Helge Deller <deller@gmx.de>,
	Parisc List <linux-parisc@vger.kernel.org>,
	"James E.J. Bottomley" <jejb@parisc-linux.org>,
	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 4/6] parisc: uapi header and system call table file generation
Date: Thu, 11 Oct 2018 09:03:51 +0200	[thread overview]
Message-ID: <CAK8P3a1Kbxue2PXRL87-Saiotyq-+v=Uc3vL9KArRuLqCwC4bw@mail.gmail.com> (raw)
In-Reply-To: <CALxhOnj1SnTO9Sm-1cAL9B8gEmYrOHr03K6OqF4qqt5Oh0x+4g@mail.gmail.com>

On Thu, Oct 11, 2018 at 8:48 AM Firoz Khan <firoz.khan@linaro.org> wrote:
> On Thu, 11 Oct 2018 at 11:40, Firoz Khan <firoz.khan@linaro.org> wrote:
> > On Wed, 10 Oct 2018 at 01:48, Helge Deller <deller@gmx.de> wrote:

> > > +
> > > +ENTRY(sys_call_table)
> > > +#if defined(CONFIG_64BIT)
> > > +#include <asm/syscall_table_c32.h>     /* compat syscalls */
> > > +#else
> > > +#include <asm/syscall_table_32.h>      /* 32-bit native syscalls */
> > > +#endif
> > > +END(sys_call_table)
> > > +
> > >  #ifdef CONFIG_64BIT
> > > -#define SYSCALL_TABLE_64BIT
> > > -#include "syscall_table_64.S"
> > > +ENTRY(sys_call_table64)
> > > +#include <asm/syscall_table_64.h>      /* 64-bit native syscalls */
> > > +END(sys_call_table64)
> > >  #endif
> > >
> > >         /*
>
> I could see a patch (commit 47514da3ac20150cdf764466fbc2010c0fca0163)
> which will perform a compile-check when adding a new syscall. My patches
> will remove this feature. Is that fine?

I think it's ok: You are automating it so the bug can no longer happen,
which is better than adding checks to prevent human errors.

        Arnd

  reply	other threads:[~2018-10-11  7:03 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
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 [this message]
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='CAK8P3a1Kbxue2PXRL87-Saiotyq-+v=Uc3vL9KArRuLqCwC4bw@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=deepa.kernel@gmail.com \
    --cc=deller@gmx.de \
    --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.