On 02/11/2013 06:46 PM, Denys Vlasenko wrote: > On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin <avagin@xxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
