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

[Pavel Emelyanov]

On 12/05/2013 07:15 AM, Andrew Vagin wrote:
> On Thu, Dec 05, 2013 at 12:18:29AM +0400, Pavel Emelyanov wrote:
>> On 12/04/2013 11:14 PM, Andrew Vagin wrote:
>>> On Wed, Dec 04, 2013 at 08:21:04PM +0400, 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.
>>>
>>> Here is nothing wrong if a library and app are static linked. We are
>>> talking about dinamic linked library. If we change something in criu, it
>>> will be changed in a libary too, but application works accoding with old
>>> headers. Are you sure that we will not have problems in this case?
>>
>> criu is not going to be linked with libcriu, what are you talking about?
>> libcriu is just a wrapper on top of rpc client.
> 
> I didn't say that criu is linked with libcriu. I said that libcriu
> is linked with an user app.
> 
> Look at this
> struct  _UnixSkEntry
> { 
>   ProtobufCMessage base;
>   uint32_t id;
>   uint32_t ino;
>   uint32_t type;
>   uint32_t state;
>   uint32_t flags;
>   uint32_t uflags;
>   uint32_t backlog;
>   uint32_t peer;
>   FownEntry *fown;
>   SkOptsEntry *opts;
>   ProtobufCBinaryData name;
>   protobuf_c_boolean has_shutdown;
>   SkShutdown shutdown;
>   FilePermsEntry *file_perms;
> };
> 
> Now let's imagine that CRIU is compiled with a new protobuf, where the
> size of ProtobufCMessage is changed.
> 
> Now we have new criu and libcriu. But out application was compiled with
> old headers. When the app starts, it loads libcriu. We have a problem,
> don't we?

We do, but that's because we leak decoded protobuf structure into
application. Library is not supposed to do it. If app wants to work
with pb structs, it should use RPC directly.