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

[Ruslan Kuprieiev]

On 04.12.2013 20:38, Pavel Emelyanov wrote:
> 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.

It will work so only if _packed_ msg is passed, because missing bits are set
to default values when unpacking.

Here is a situation: old app uses new libcriu. new resp is send to new 
libcriu. new libcriu unpacks it and
returns unpacked new resp to old app. But new unpacket resp != old 
unpacked resp -- looks bad to me.
But if new libcriu returns packed new resp to old app, then protobuf 
will be able to truncate it and
unpack into old resp, so app can use it.

> Thanks,
> Pavel