From: Gabriel Krisman Bertazi <gabriel@krisman.be>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: Doug Evans <dje@google.com>, gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC PATCH 2/3] Add support to catch groups of syscalls.
Date: Sun, 12 Oct 2014 21:37:00 -0000 [thread overview]
Message-ID: <87k34555se.fsf@anubis.Home> (raw)
In-Reply-To: <87siiy9vis.fsf@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2597 bytes --]
Sergio Durigan Junior <sergiodj@redhat.com> writes:
> On Wednesday, October 08 2014, Doug Evans wrote:
>
>> Regarding:
>>> # catch syscalls write, read, chdir, and groups network and signal
>>> (gdb) catch syscall write read chdir -g network,signal
>>> # or maybe without comma-separated values for groups, to keep consistency
>>> (gdb) catch syscall write read chdir -g network signal
>>
>> I dislike "network,signal" if we don't also accept "read,write". I
>> gather the comma is there to remove ambiguity as to what "-g network
>> signal" means.
>
> Yeah.
>
>> I also kinda dislike interpreting "-g" to mean all remaining arguments
>> (for a few reasons).
>
> Since there are very few groups (compared to syscalls names), I also
> thought that "-g" could be used multiple times, like:
>
> (gdb) catch syscall -g network -g signal
>
> But...
Doug and Sergio,
Thank you for your review and valuable suggestions.
The suggestion I feel more comfortable with is using -g for each syscall
group. I agree that syscall groups should be treated on a different
namespace than syscall names, which are the expected argument for a
command called "catch syscall".
>> How about appending "-group" or some such to group names?
>
> Hm, it seems OK, but I am thinking about one specific syscall that might
> make things confusing here: exit_group(2). Consider:
>
> (gdb) catch syscall signal-group exit_group
>
> This can be very confusing for the user.
>
>> [I don't want to have too long a discussion or be too picky.
>> OTOH I also don't want to just pick something and then regret it.]
>
> Yeah, I understand your reasons.
>
> Along the lines of your proposal above, I guess we can add a "g:" prefix
> to group names:
>
> (gdb) catch syscall read chdir g:network g:signal signal
>
> WDYT?
I dislike the proposal of adding prefixes/suffixes to the group names
because I feel it might be harder to type, and also because it feels a
little unusual, if we consider the common way of providing arguments to
commands.
Using -g to specify syscall groups, as Sergio said, has also the
advantage of providing us with an intuitive command to list available
syscall groups, by saying "catch syscall -g" with no arguments.
So, my vote goes to using '-g' for each syscall group we want to
catch. Is that ok for you, guys?
I will still wait a few days to see if anyone has more suggestions
before sending the updated patch that fixes the syntax and the other
things you guys pointed out.
Thanks!
--
Gabriel Krisman Bertazi
[-- Attachment #2: Type: application/pgp-signature, Size: 818 bytes --]
next prev parent reply other threads:[~2014-10-12 21:37 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-08 2:51 [RFC PATCH 0/3] Catch syscall group Gabriel Krisman Bertazi
2014-10-08 2:51 ` [RFC PATCH 2/3] Add support to catch groups of syscalls Gabriel Krisman Bertazi
2014-10-08 19:07 ` Sergio Durigan Junior
2014-10-08 19:46 ` Doug Evans
2014-10-08 20:48 ` Sergio Durigan Junior
2014-10-12 21:37 ` Gabriel Krisman Bertazi [this message]
2014-10-12 22:52 ` Sergio Durigan Junior
2014-10-13 16:49 ` Doug Evans
2014-10-20 4:52 ` Gabriel Krisman Bertazi
2014-10-20 19:39 ` Sergio Durigan Junior
2014-10-27 19:20 ` Doug Evans
2014-10-08 2:51 ` [RFC PATCH 1/3] Implemement support for groups of syscalls in the xml-syscall interface Gabriel Krisman Bertazi
2014-10-08 17:21 ` Sergio Durigan Junior
2014-10-08 2:52 ` [RFC PATCH 3/3] Create syscall groups for x86_64 Gabriel Krisman Bertazi
2014-10-08 19:00 ` Sergio Durigan Junior
2014-10-08 16:10 ` [RFC PATCH 0/3] Catch syscall group Sergio Durigan Junior
2014-10-12 21:12 ` Gabriel Krisman Bertazi
2014-10-12 22:55 ` Sergio Durigan Junior
2014-10-08 16:12 ` Doug Evans
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=87k34555se.fsf@anubis.Home \
--to=gabriel@krisman.be \
--cc=dje@google.com \
--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