From mboxrd@z Thu Jan 1 00:00:00 1970 From: Oleg Nesterov Subject: Re: [PATCH] ptrace: add ability to retrieve signals without removing them from a queue Date: Fri, 15 Feb 2013 20:43:56 +0100 Message-ID: <20130215194356.GA12413@redhat.com> References: <1360768595-31943-1-git-send-email-avagin@openvz.org> <511E8223.6010506@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <511E8223.6010506-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Pedro Alves Cc: Andrey Vagin , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, criu-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org, linux-api-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Andrew Morton , "Paul E. McKenney" , David Howells , Dave Jones , "Michael Kerrisk (man-pages)" , Pavel Emelyanov , Linus Torvalds List-Id: linux-api@vger.kernel.org On 02/15, Pedro Alves wrote: > > Not sure I'm reading the patch right, but it looks like GDB would > be able to use this as alternative to PTRACE_GET_SIGINFO variant No, it is different. PTRACE_GETSIGINFO reports the siginfo for the signal which was already dequeued (ignoring the fact ->last_siginfo != NULL doesn't necessarily mean we report a signal), while this patch allows to look at the pending signals which were not reported yet. > I wouldn't mind if this was added unconditionally > instead of wrapped on CONFIG_CHECKPOINT_RESTORE. I agree. If you think gdb can use this new feature, CONFIG_ can go away. > 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. Oleg.