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

[Pavel Emelyanov]

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

Messages are not sent _to_ libcriu, but _by_ libcriu.

> 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
> 
> .
>