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

[Ruslan Kuprieiev]

On 04.12.2013 20:21, 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.

Lets take a look at situation that was described by Andrew.
Application was compiled with old protobuf header, where some msg structure
looks like this:

struct msg {
     bool a;
}

Then, libcriu was updated and in libcriu msg looks like this:

struct msg {
     bool a;
     bool b;
}

I'm not sure what exactly will happen here, but something bad, I suppose.

>
> Thanks,
> Pavel
>