Messages in this thread |  | | Date | Mon, 11 Feb 2013 18:53:11 +0400 | From | Pavel Emelyanov <> | Subject | Re: [CRIU] [PATCH 3/3] signalfd: add ability to read siginfo-s without dequeuing signals (v2) |
| |
On 02/11/2013 06:46 PM, Denys Vlasenko wrote: > On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin <avagin@parallels.com> wrote: >>>> I suppose I had wondered along similar lines, but in a slightly >>>> different direction: would the use of a /proc interface to get the >>>> queued signals make some sense? >>> >>> I think that /proc interface beats adding magic flags and magic semantic >>> to [p]read. >>> >>> It also has the benefit of being human-readable. You don't need >>> to write a special C program to "cat /proc/$$/foo". >>> >>> Andrey, I know that it is hard to let go of the code you invested time >>> and efforts in creating. But this isn't the last patch, is it? >>> You will need to retrieve yet more data for process checkpointing. >>> When you start working on the next patch for it, consider trying >>> /proc approach. >> >> I don't think that we need to convert siginfo into a human readable format >> in kernel. > > My point is that bolting hacks onto various bits of kernel API > in order to support process checkpointing makes those APIs > (their in-kernel implementation) ridden with special cases > and harder to support in the future. > > Process checkpointing needs to bite the bullet and > create its own API instead.
This is bad approach as well. What we should do is come up with a sane API that makes sense without the checkpoint-restore project _when_ _possible_.
> Whether it would be a /proc/PID/checkpoint or a > ptrace(PTRACE_GET_CHKPOINT_DATA) is another question.
Thanks, Pavel
|  |