[CRIU] Re: [RFC 0/4] Lets try PB again

Stanislav Kinsbursky skinsbursky at parallels.com
Fri Jul 6 10:19:47 EDT 2012


06.07.2012 16:50, Pavel Emelyanov пишет:
> On 07/06/2012 04:35 PM, Cyrill Gorcunov wrote:
>> On Fri, Jul 06, 2012 at 04:21:25PM +0400, Pavel Emelyanov wrote:
>>>
>>> Is there a way to unpack an object into a static buffer rather than
>>> allocating one dynamically?
>>
>> Yes, previously I've been using 16K stack for that, I can bring it back ;)
>>
>> +#define pbimg_write_obj(__fd, __object, __type, __get_packed_size, __pack)
>> +({
>> +	u8  ___buf[KILO(16)];
>> +	u32 ___size = __get_packed_size(__object);
>> +	int ___ret = -1;
>>
>> that is from previous versions. If buffer is too small we will ge error.
>> But in most case 16K is more than enough ;)
>
> No, I meant a bit different thing. Instead of
>
> FooEntry *foo;
>
> foo = foo_entry__unpack();
> ...
> foo_entry__free_unpacked();
>
> write
>
> FooEntry foo;
>
> foo_entry__unpack_on_staack(&foo);
>
> Is it possible? If no, then OK, let's proceed with this approach.
>
>>>> +			fdinfo_entry__get_packed_size,
>>>> +			fdinfo_entry__pack);
>>>
>>> I'd appreciate if this looked like
>>>
>>> pc_write(fd, &e, fdinfo_entry);
>>>
>>> where __get_packet_size and __pack are concatenated inside the macro
>>
>> yeah, good point, will update
>>
>>>> +#define pb_write(__fd, __obj_ptr, __get_pksize, __pack)				\
>>>> +({										\
>>>> +	u32 __size = __get_pksize(__obj_ptr);					\
>>>> +	u8 *__buf = xmalloc(__size);						\
>>>> +	int __ret = -1;								\
>>>> +										\
>>>> +	if (__buf) {								\
>>>> +		__pack(__obj_ptr, __buf);					\
>>>> +		__ret = write_img(__fd, &__size);				\
>>>> +		if (!__ret)							\
>>>> +			__ret = write_img_buf(__fd, __buf, __size);		\
>>>> +		xfree(__buf);							\
>>>> +	}									\
>>>> +										\
>>>> +	__ret;									\
>>>> +})
>>>
>>> That's too big for a macro. Turn it into a macro + outlined function.
>>
>> I've been trying, but the problem is that PB compiler generates pack/unpack
>> prototypes with argument typed and I can't use some abstract function which
>> has void* types as arguments, gcc complains. So I switched to macros.
>
> Well, I think for _that_ case it's OK to use very abstract casting
> like this (*)() ;)
>


I'd prefer, if some comment will be added for this hack, because hiding of 
incoming variables in prototypes is a nasty technique.
I.e. why we do so and what for.


>> 	Cyrill
>> _______________________________________________
>> CRIU mailing list
>> CRIU at openvz.org
>> https://openvz.org/mailman/listinfo/criu
>> .
>>
>


-- 
Best regards,
Stanislav Kinsbursky





More information about the CRIU mailing list