Re: [CRIU] [PATCH 3/3] signalfd: add ability to read siginfo-s without dequeuing signals (v2)

On Mon, Feb 11, 2013 at 11:59 AM, Andrew Vagin [off-list ref] wrote:

quoted

quoted

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.

Whether it would be a /proc/PID/checkpoint or a
ptrace(PTRACE_GET_CHKPOINT_DATA) is another question.

-- 
vda