[CRIU] [PATCH 8/8] test: libcriu

Pavel Emelyanov xemul at parallels.com
Wed Dec 4 12:18:29 PST 2013


On 12/04/2013 11:14 PM, Andrew Vagin wrote:
> On Wed, Dec 04, 2013 at 08:21:04PM +0400, Pavel Emelyanov wrote:
>>>>>>>> +int main(int argc, char *argv[])
>>>>>>>> +{
>>>>>>>> +    int ret;
>>>>>>>> +    CriuOpts opts    = CRIU_OPTS__INIT;
>>>>>>>> +    CriuResp *resp    = NULL;
>>>>>>> protobuf guarantees compatibility only for packed objects
>>>>>> Excuse me, could you please explain what do you mean?
>>>>> If you add a new field in the CriuResp protobuf, you can't be sure, that
>>>>> all old applications will continue work with a new CRIU binaries.
>>>>>
>>>>> Old applications was compiled with old headers, but they will load
>>>>> the new CRIU library.
>>>>
>>>> Oh, good point. So, I suppose, we just need to return packet resp?
>>>
>>> So, we can't pack\unpack anything in libcriu without ruining compatibility.
>>> Looks like the only thing libcriu may be used for is connect to socket and
>>> send\recv data, without processing it. But isn't it pointless to create 
>>> library like this?
>>> I honestly can't see any further a reason to create libcriu. Maybe just let
>>> people use RPC?
>>
>> What's wrong with getting stream from socket and unpacking it into message
>> right in the library? You don't have to exchange objects between criu and
>> library.
> 
> Here is nothing wrong if a library and app are static linked. We are
> talking about dinamic linked library. If we change something in criu, it
> will be changed in a libary too, but application works accoding with old
> headers. Are you sure that we will not have problems in this case?

criu is not going to be linked with libcriu, what are you talking about?
libcriu is just a wrapper on top of rpc client.

> 
>>
>> Thanks,
>> Pavel
>>
> .
> 




More information about the CRIU mailing list