[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <511E9480.5070202@redhat.com>
Date: Fri, 15 Feb 2013 20:03:12 +0000
From: Pedro Alves <palves@...hat.com>
To: Oleg Nesterov <oleg@...hat.com>
CC: Andrey Vagin <avagin@...nvz.org>, linux-kernel@...r.kernel.org,
criu@...nvz.org, linux-api@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
David Howells <dhowells@...hat.com>,
Dave Jones <davej@...hat.com>,
"Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>,
Pavel Emelyanov <xemul@...allels.com>,
Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] ptrace: add ability to retrieve signals without removing
them from a queue
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists