From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Gabriel Krisman Bertazi <gabriel@krisman.be>,
gdb-patches@sourceware.org, dje@google.com
Subject: Re: [PATCH v3 00/17] Catch syscall group
Date: Wed, 29 Apr 2015 10:44:00 -0000 [thread overview]
Message-ID: <5540ABF8.4000404@redhat.com> (raw)
In-Reply-To: <87r3r42e0v.fsf@redhat.com>
On 04/28/2015 09:28 PM, Sergio Durigan Junior wrote:
> On Tuesday, April 28 2015, Pedro Alves wrote:
>
>> I was wondering if we couldn't share most of the grouping
>> per-architecture, e.g., by having each arch syscall file xi:include a
>> base Linux default groups file, that listed the grouping without
>> the syscall number. E.g., create a linux-defaults.xml like:
>>
> Thanks for the review, Pedro. I think this is a nice idea, but I would
> like to propose that we accept the patches as-is, without this
> improvement, and then work on it later. First, it's been a long time
> since we're discussing this feature, and I don't want Krisman to not
> feel encouraged to continue contributing :-).
I think there's a difference from the feature itself, which was
discussed and I'm generally fine with, and the whole set of patches that are
new in this new revision of the series. Those are revealing a problem
that I think should be addressed.
> Also, I think the syscall
> XML generation really needs a revamp, independently of how/if we use
> groups or not. There should be possible, for example, to easily update
> the XML's with the latest Linux kernel source. This task is on my
> plate, though it's a low priority. So, for now, I think Krisman's work
> is good enough.
Updating the XML's from the Linux source is a different thing. That
would only regenerate the set of syscalls and its numbers. The grouping
is not something that can be extracted out of the kernel.
Note Gabriel is already using scripts to generate the xmls (hence
my questions in the previous email):
> The previous version only implemented syscalls for amd64. I used a
> script to generate the xmls, and based the group field information on
> strace, so please share your thoughts if you disagree with any group.
... and this shows the issue that I'm seeing: we have seemingly the
same grouping done _14_ times. That's not a sign of something that
is maintainable.
Maybe the linux-defaults.xml idea was overcomplicated. The main
take away is that the syscall grouping should be the same
everywhere, which suggests that the xml files in their current
xml scheme should be generated. The existing xml files map the syscall
names to syscall numbers, and that necessarily need to be per-architecture.
I'm super fine with adding the "groups" attribute to each
arch file. But we can centralize that. It does not have to be a
complicated thing at all. Something like:
- rename the existing files:
$arch-linux.xml -> $arch-xml.in
- add a simple linux-defaults file, containing a simple table, like:
~~~
# First column is syscall name, second column is syscall groups.
...
signalfd4 descriptor,signal
vfork process
...
~~~
And then add a build step that with a simple perl/python/awk/sed/whatever
script goes over each line of that table and seds each $arch-linux-xml.in
the file transforming:
name="$first_column"
into
name="$first_column" groups="$second_column"
etc.
E.g., from:
<syscall name="signalfd4" number="289"/>
to:
<syscall name="signalfd4" groups="descriptor,signal" number="289"/>
That is, a simple text substitution.
This makes is much easier to
- review
- maintain
- extend for future syscalls / groups
- extend for future architectures
than the same info in 14 (and counting) different files, probably
all in agreement with each other, but pretty much unverifiable.
> In sum: I propose we go ahead now ("don't let the perfect be the enemy
> of the good"), and concentrate on the XML problem later.
I'd like to hear what Gabriel thinks (both of my questions in the
previous email, and this one).
If there are grouping differences between the architectures (other
than which syscalls are wired/supported), Gabriel will have noticed
them, but that knowledge is lost (not encoded anywhere) in the
current form.
As a quick experiment, I did (which Gabriel's grouping patches applied):
$ cat amd64-linux.xml | sed 's/ number=\"[0-9]*\"//g' | sort > amd64-linux-no-number.xml
$ cat ppc-linux.xml | sed 's/ number=\"[0-9]*\"//g' | sort > ppc-linux-no-number.xml
$ diff -up amd64-linux-no-number.xml ppc-linux-no-number.xml
and saw no difference in the grouping, but I did not do that
for all archs.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2015-04-29 10:01 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-26 1:25 Gabriel Krisman Bertazi
2015-04-26 1:25 ` [PATCH v3 02/17] Add support to catch groups of syscalls Gabriel Krisman Bertazi
2015-04-26 1:25 ` [PATCH v3 03/17] Add tests for catching groups of syscalls on supported architectures Gabriel Krisman Bertazi
2015-04-26 18:44 ` Sergio Durigan Junior
2015-04-26 1:25 ` [PATCH v3 01/17] Implemement support for groups of syscalls in the xml-syscall interface Gabriel Krisman Bertazi
2015-04-26 1:26 ` [PATCH v3 12/17] Create syscall groups for mips-n64 Gabriel Krisman Bertazi
2015-04-26 1:26 ` [PATCH v3 06/17] Create syscall groups for ppc64 Gabriel Krisman Bertazi
2015-04-26 1:26 ` [PATCH v3 07/17] Create syscall groups for aarch64 Gabriel Krisman Bertazi
2015-04-26 1:26 ` [PATCH v3 05/17] Create syscall groups for ppc Gabriel Krisman Bertazi
2015-04-26 1:26 ` [PATCH v3 04/17] Create syscall groups for amd64 Gabriel Krisman Bertazi
2015-04-26 1:26 ` [PATCH v3 10/17] Create syscall groups for i386 Gabriel Krisman Bertazi
2015-04-26 1:26 ` [PATCH v3 08/17] Create syscall groups for arm Gabriel Krisman Bertazi
2015-04-26 1:26 ` [PATCH v3 09/17] Create syscall groups for bfin Gabriel Krisman Bertazi
2015-04-26 1:47 ` [PATCH v3 11/17] Create syscall groups for mips-n32 Gabriel Krisman Bertazi
2015-04-26 1:47 ` [PATCH v3 14/17] Create syscall groups for s390 Gabriel Krisman Bertazi
2015-04-26 1:47 ` [PATCH v3 13/17] Create syscall groups for mips-o32 Gabriel Krisman Bertazi
2015-04-26 1:47 ` [PATCH v3 15/17] Create syscall groups for s390x Gabriel Krisman Bertazi
2015-04-26 1:47 ` [PATCH v3 17/17] Create syscall groups for sparc64 Gabriel Krisman Bertazi
2015-04-26 1:47 ` [PATCH v3 16/17] Create syscall groups for sparc Gabriel Krisman Bertazi
2015-04-26 18:58 ` [PATCH v3 00/17] Catch syscall group Sergio Durigan Junior
2015-04-28 11:24 ` Pedro Alves
2015-04-29 0:45 ` Sergio Durigan Junior
2015-04-29 10:44 ` Pedro Alves [this message]
2015-05-04 2:34 ` Gabriel Krisman Bertazi
2015-05-06 14:38 ` Pedro Alves
2015-05-10 18:34 ` Gabriel Krisman Bertazi
2015-05-10 19:01 ` Sergio Durigan Junior
2015-05-11 0:28 ` [PATCH v4 0/4] catch " Gabriel Krisman Bertazi
2015-05-11 0:28 ` [PATCH v4 4/5] Include group information in xml syscall files Gabriel Krisman Bertazi
2015-05-12 21:42 ` Doug Evans
2015-05-13 1:17 ` Gabriel Krisman Bertazi
2015-05-13 10:43 ` Pedro Alves
2015-05-11 0:28 ` [PATCH v4 1/5] Implemement support for groups of syscalls in the xml-syscall interface Gabriel Krisman Bertazi
2015-05-11 0:28 ` [PATCH v4 5/5] Update documentation on catching a group of related syscalls Gabriel Krisman Bertazi
2015-05-11 0:40 ` Gabriel Krisman Bertazi
2015-05-13 10:30 ` Pedro Alves
2015-05-13 16:40 ` Eli Zaretskii
2015-05-11 0:28 ` [PATCH v4 3/5] Add tests for catching groups of syscalls on supported architectures Gabriel Krisman Bertazi
2015-05-11 0:28 ` [PATCH v4 2/5] Add support to catch groups of syscalls Gabriel Krisman Bertazi
2015-05-13 10:38 ` Pedro Alves
2015-05-13 10:47 ` [PATCH v4 0/4] catch syscall group Pedro Alves
2015-05-11 11:39 ` [PATCH v3 00/17] Catch " Pedro Alves
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=5540ABF8.4000404@redhat.com \
--to=palves@redhat.com \
--cc=dje@google.com \
--cc=gabriel@krisman.be \
--cc=gdb-patches@sourceware.org \
--cc=sergiodj@redhat.com \
/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