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

[Andrew Vagin]

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?
> 
> > 
> >>
> >> Thanks,
> >> Pavel
> >>
> > .
> > 
> 
>