[CRIU] [PATCH 1/2] IPC: message queue copy feature introduced

[Pavel Emelyanov]

On 08/09/2012 02:21 PM, Stanislav Kinsbursky wrote:
> 09.08.2012 13:53, Pavel Emelyanov пишет:
>> On 08/09/2012 01:25 PM, Stanislav Kinsbursky wrote:
>>> 09.08.2012 12:47, Pavel Emelyanov пишет:
>>>> On 08/09/2012 12:40 PM, Stanislav Kinsbursky wrote:
>>>>> This patch is required for checkpoint/restore in userspace.
>>>>> IOW, c/r requires some way to get all pending IPC messages without deleting
>>>>> them from the queue (checkpoint can fail and in this case tasks will be resumed,
>>>>> so queue have to be valid).
>>>>> To achive this, new operation flag MSG_COPY for sys_msgrcv() system call was
>>>>> introduced. Also, copy counter was added to msg_queue structure. It's set to
>>>>> zero by default and increases by one on each copy operation and decreased by
>>>>> one on each receive operation until reaches zero.
>>>>
>>>> I think we should specify the copy_cnt semantics more strictly. How does
>>>> it correlate with message types?
>>>>
>>>
>>> What do you mean?
>>> It doesn't correlate at all - syscall logic remains the same.
>>> I.e. if you specify message type, then you'll copy n-th message on desired type.
>>
>> That's exactly what I asked -- this number is the n-th message of desired type,
>> thanks.
>>
>> Next issue: I'm bothered by the amount of #ifdef-s over the code.
>>
> 
> Me too. Any simple solutions?

Introduce

#ifdef CONFIG_CHECKPOINT_RESTORE
#define queue_copy_count_fwd(q)	do { q->copy_cnt++; } while (0)
#define queue_copy_count_bwd(q) do { q->copy_cnt++; } while (0)
#else
#define queue_copy_count_fwd(q) do { } while (0)
#define queue_copy_count_bwd(q) do { } while (0)
#endif

and similar stiff and use where appropriate.

> Rewrite all the logic to reduce #ifdef-s count is unacceptable.