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

[Ruslan Kuprieiev]

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

Yes, but they are processed by libcriu too.

Maybe I get something wrong.
Andrew, what do you think?

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