[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