On 02/15/2013 07:43 PM, Oleg Nesterov wrote: > 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. Ah, I had assumed queue position 0 would be the dequeued signal. >> 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. I think so -- we can add a gdb command to dump the list of pending signals, which I think is something that'd be useful. > >> 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. -- Pedro Alves -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
