From: Pedro Alves <palves@redhat.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Andrey Vagin <avagin@openvz.org>,
linux-kernel@vger.kernel.org, criu@openvz.org,
linux-api@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
David Howells <dhowells@redhat.com>,
Dave Jones <davej@redhat.com>,
"Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
Pavel Emelyanov <xemul@parallels.com>,
Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] ptrace: add ability to retrieve signals without removing them from a queue
Date: Fri, 15 Feb 2013 20:03:12 +0000 [thread overview]
Message-ID: <511E9480.5070202@redhat.com> (raw)
In-Reply-To: <20130215194356.GA12413@redhat.com>
Forgot to reply to this bit:
On 02/15/2013 07:43 PM, Oleg Nesterov wrote:
>> We'd miss the poke
>> > variant, but that looks like something that could be always be added
>> > later.
> Yes. _POKE_ or _QUEUE_ or _DEQUEUE_, we can add more features if user-
> space wants them.
In general, IMO, I agree with Roland at https://lkml.org/lkml/2002/12/20/84
in that it's good to have setters for completeness, so that you can
change all the state via ptrace that you can read via ptrace.
But I'm not doing any of this work, hence my "could always be
added later" comment instead of actually requesting it. But if
we had it, we could make e.g., gdb inspect the signal queues,
and then be able to tweak a realtime signal before it is
delivered.
--
Pedro Alves
next prev parent reply other threads:[~2013-02-15 20:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-13 15:16 [PATCH] ptrace: add ability to retrieve signals without removing them from a queue Andrey Vagin
[not found] ` <1360768595-31943-1-git-send-email-avagin-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2013-02-13 16:06 ` Oleg Nesterov
2013-02-15 18:44 ` Pedro Alves
[not found] ` <511E8223.6010506-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-02-15 19:43 ` Oleg Nesterov
[not found] ` <20130215194356.GA12413-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-02-15 19:53 ` Pedro Alves
2013-02-15 20:03 ` Pedro Alves [this message]
[not found] ` <511E9480.5070202-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-02-19 9:39 ` Andrey Wagin
2013-02-19 12:15 ` Michael Kerrisk (man-pages)
[not found] ` <CAKgNAkicAGEkvNFnSso__wK6QKao8jyDu5yuRmeyUOeaXLGChw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2013-02-19 17:53 ` Pavel Emelyanov
2013-02-19 19:34 ` Oleg Nesterov
[not found] ` <20130219193424.GA9606-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-02-19 19:47 ` Pavel Emelyanov
[not found] ` <5123D6D6.7010904-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2013-02-20 22:37 ` Oleg Nesterov
[not found] ` <20130220223703.GB16194-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-02-21 10:30 ` Pavel Emelyanov
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=511E9480.5070202@redhat.com \
--to=palves@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@openvz.org \
--cc=criu@openvz.org \
--cc=davej@redhat.com \
--cc=dhowells@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mtk.manpages@gmail.com \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=xemul@parallels.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;
as well as URLs for NNTP newsgroup(s).