[CRIU] Re: [PATCH v2 1/3] IPC: dump shared memory

[Kinsbursky Stanislav]

03.02.2012 21:13, Pavel Emelyanov пишет:
> On 02/03/2012 09:00 PM, Kinsbursky Stanislav wrote:
>>
>> Signed-off-by: Stanislav Kinsbursky<skinsbursky at parallels.com>
>>
>> ---
>>   include/image.h |   11 +++++
>>   ipc_ns.c        |  112 +++++++++++++++++++++++++++++++++++++++++++++++++------
>>   2 files changed, 111 insertions(+), 12 deletions(-)
>>
>> diff --git a/include/image.h b/include/image.h
>> index 8e6a000..fd52bb0 100644
>> --- a/include/image.h
>> +++ b/include/image.h
>> @@ -121,6 +121,17 @@ struct ipc_ns_entry {
>>   	u32	in_use[3];
>>   } __packed;
>>
>> +struct ipc_shm_entry {
>> +	u32	key;
>> +	u32	uid;
>> +	u32	gid;
>> +	u32	cuid;
>> +	u32	cgid;
>> +	u32	mode;
>> +	u64	size;
>> +	u32	id;
>> +} __packed;
>> +
>>   #define VMA_AREA_NONE		(0<<   0)
>>   #define VMA_AREA_REGULAR	(1<<   0)	/* Dumpable area */
>>   #define VMA_AREA_STACK		(1<<   1)
>> diff --git a/ipc_ns.c b/ipc_ns.c
>> index 3336d8c..34a4c92 100644
>> --- a/ipc_ns.c
>> +++ b/ipc_ns.c
>> @@ -15,6 +15,7 @@
>>
>>   struct ipc_ns_data {
>>   	struct ipc_ns_entry entry;
>> +	struct ipc_shm_entry *shm;
> What's the profit in first collecting this stuff and then dumping? Why now
> write it right into a file at the time of reading from kernel?

I don't have any strong arguments against reading and writing data at once.
Currently, it just looks easier to me. I.e. we have some restrictions to IPC ns 
migration. Currently it's sems and message queues. But check for IPC ns 
consistency (i.e. that no IPC ns parts will left beyond subtree we are dumping)  
before dump should be added in future. And thus better to make sure that no of 
them meet before dump.


-- 
Best regards,
Stanislav Kinsbursky