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

[Pavel Emelyanov]

On 12/04/2013 11:33 PM, Ruslan Kuprieiev wrote:
> 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.

Nothing bad will happen. CRIU will serialize this new struct into a
bytes-sequence, and library will decode one into whatever structure
it understands. This is what protobuf is supposed to do.

Provided fields, that differ are marked as optional everything would
be fine, just missing bits will contain default values.

Thanks,
Pavel