From: Arnd Bergmann <arnd@arndb.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Marcin Nowakowski <marcin.nowakowski@imgtec.com>,
Linux API <linux-api@vger.kernel.org>,
Ingo Molnar <mingo@redhat.com>,
open list <linux-kernel@vger.kernel.org>,
Linux MIPS Mailing List <linux-mips@linux-mips.org>
Subject: Re: [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers per syscall
Date: Wed, 31 Aug 2016 10:24:56 +0200 [thread overview]
Message-ID: <5227283.eAVLXfitJh@wuerfel> (raw)
In-Reply-To: <CALCETrXA0XbYuqYzWMJA+KjFS31YL0cTVtrvCnmRY_GMK6oNpw@mail.gmail.com>
On Tuesday, August 30, 2016 12:53:53 PM CEST Andy Lutomirski wrote:
> Egads! OK, I see why this is a mess.
>
> I guess we should be creating the metadata from the syscall tables
> instead of from the syscall definitions, but I guess that's currently
> a nasty per-arch mess.
>
I've been thinking for a while about how to improve the situation
around adding new syscalls, which currently involves adding a number
and an entry in a .S file on most architectures (some already have
their own method to simplify it, and others using a shared table
in asm-generic).
I was thinking of extending the x86 way of doing this to all
architectures, and adding a way to have all future syscalls require
only one addition in a single file that gets included by the
architecture specific files for the existing syscalls.
Assuming we do this, would that work for generating the metadata
from the same file like we do with
arch/x86/entry/syscalls/syscall{tbl,hdr}.sh ?
Arnd
next prev parent reply other threads:[~2016-08-31 8:25 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 9:30 [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers per syscall Marcin Nowakowski
2016-08-29 9:30 ` [PATCH 2/2] MIPS: set NR_syscall_tables appropriately Marcin Nowakowski
2016-09-27 12:04 ` Ralf Baechle
2016-09-28 6:58 ` Marcin Nowakowski
2016-08-29 23:55 ` [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers per syscall Andy Lutomirski
2016-08-30 8:14 ` Marcin Nowakowski
2016-08-30 18:52 ` Andy Lutomirski
2016-08-30 19:29 ` Steven Rostedt
2016-08-30 19:53 ` Andy Lutomirski
2016-08-30 20:58 ` Steven Rostedt
2016-08-30 21:45 ` Andy Lutomirski
2016-08-30 22:03 ` Steven Rostedt
2016-08-30 22:08 ` Andy Lutomirski
2016-08-30 22:30 ` Steven Rostedt
2016-08-30 23:09 ` Andy Lutomirski
2016-08-30 23:28 ` Steven Rostedt
2016-08-31 0:01 ` Andy Lutomirski
2016-08-31 14:08 ` Marcin Nowakowski
2016-08-31 7:00 ` Marcin Nowakowski
2016-08-31 8:24 ` Arnd Bergmann [this message]
2016-09-01 15:24 ` Steven Rostedt
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=5227283.eAVLXfitJh@wuerfel \
--to=arnd@arndb.de \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=luto@amacapital.net \
--cc=marcin.nowakowski@imgtec.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).