From: Denys Vlasenko <vda.linux@googlemail.com>
To: Tejun Heo <tj@kernel.org>
Cc: Denys Vlasenko <dvlasenk@redhat.com>,
Oleg Nesterov <oleg@redhat.com>,
linux-kernel@vger.kernel.org
Subject: Re: Why I want PTRACE_O_TRACESTOP option
Date: Fri, 9 Sep 2011 07:54:50 +0200 [thread overview]
Message-ID: <201109090754.50272.vda.linux@googlemail.com> (raw)
In-Reply-To: <20110909001853.GA29319@htj.dyndns.org>
On Friday 09 September 2011 02:18, Tejun Heo wrote:
> Hello, Denys.
>
> On Thu, Sep 08, 2011 at 06:50:01PM +0200, Denys Vlasenko wrote:
> > Consider what will happen when a next ptrace fix will require
> > a way to change ptrace API at runtime. A new option will likely
> > be introduced, say, PTRACE_O_TRACEPONY, with next available
> > bit position 7, and perhaps some new event will be generated,
> > PTRACE_EVENT_PONY, with value.... yes, it can't be 7,
> > PTRACE_EVENT_STOP took it. So it will probably be 8.
>
> Then, just give it the next matching number.
My point is that previously, ptrace behavior was modified by setting
options. Why don't we use this mechanism? Why we invent a different
wheel? Ptrace is ugly as-is, why complicate it even further?
The argument was that SETOPTIONS wasn't suitable for modifying
attach behavior, but this is fixed by "set options on SEIZE"
patch. I don't see why we can't use options mechanist to affect
group-stop behavior now.
--
vda
next prev parent reply other threads:[~2011-09-09 5:54 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-08 16:50 Why I want PTRACE_O_TRACESTOP option Denys Vlasenko
2011-09-09 0:18 ` Tejun Heo
2011-09-09 5:45 ` Denys Vlasenko
2011-09-09 16:00 ` Oleg Nesterov
2011-09-10 23:43 ` Tejun Heo
2011-09-09 5:54 ` Denys Vlasenko [this message]
2011-09-09 12:26 ` Indan Zupancic
2011-09-09 13:01 ` Indan Zupancic
2011-09-09 16:46 ` Denys Vlasenko
2011-09-09 16:26 ` Oleg Nesterov
2011-09-09 23:09 ` Indan Zupancic
2011-09-10 1:17 ` Denys Vlasenko
2011-09-10 11:20 ` Pedro Alves
2011-09-11 0:58 ` Tejun Heo
2011-09-09 16:14 ` Oleg Nesterov
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=201109090754.50272.vda.linux@googlemail.com \
--to=vda.linux@googlemail.com \
--cc=dvlasenk@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=tj@kernel.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.