[CRIU] Process Migration using Sockets - PATCH 1/2

[Rodrigo Bruno]

Hi,

On Mon, 28 Sep 2015 11:28:21 +0200
Adrian Reber <adrian at lisas.de> wrote:

> On Sat, Sep 26, 2015 at 11:45:49PM +0100, Rodrigo Bruno wrote:
> > sorry about the previous patch, I obviously got it wrong...
> > 
> > I hope this one is right, otherwise I will re-iterate the process.
> > 
> > Signed-off-by: Rodrigo Bruno <rbruno at gsd.inesc-id.pt>
> > 
> > >From feb41dff0e2a573e713101f2f108adc893f157d1 Mon Sep 17 00:00:00 2001
> > From: rbruno <rbruno at gsd.inesc-id.pt>
> > Date: Sat, 26 Sep 2015 22:55:01 +0100
> > Subject: [PATCH 1/2] Criu remote migration using sockets. Patch 1/2.
> > 
> > ---
> >  image-remote.c              | 399 ++++++++++++++++++++++++++++++++++++++++++++
> >  include/image-remote.h      |  84 ++++++++++
> >  protobuf/remote-image.proto |   8 +
> >  3 files changed, 491 insertions(+)
> >  create mode 100644 image-remote.c
> >  create mode 100644 include/image-remote.h
> >  create mode 100644 protobuf/remote-image.proto
> > 
> > diff --git a/image-remote.c b/image-remote.c
> > new file mode 100644
> > index 0000000..cce1f13
> > --- /dev/null
> > +++ b/image-remote.c
> > @@ -0,0 +1,399 @@
> > +#include <unistd.h>
> > +#include <stdlib.h>
> > +#include <sys/types.h>
> > +#include <sys/socket.h>
> > +#include <netinet/in.h>
> > +#include <netdb.h>
> > +
> > +#include "protobuf.h"
> > +#include "protobuf/remote-image.pb-c.h"
> > +
> > +#include "criu-log.h"
> > +#include "image-remote.h"
> > +
> > +#define PB_REMOTE_IMAGE_SIZE PATHLEN
> > +
> > +static char** parents = NULL;
> > +static int  parents_occ = 0;
> > +static char* namespace = NULL;
> 
> I had a quick look at your patch and two things are a bit confusing. I
> have no idea what 'occ' in 'parents_occ' stands for. 

This variable is a counter, telling how many elements we have inside the char*
array 'parents'. 'occ' would stand for occupancy. The 'parents' array contains
all namespaces starting with the oldest until the current one.

> So some description
> what this is would be nice. The other thing that is confusing is the
> usage of namespace in combination with pre-dumps. Reading something
> about namespaces in combination with CRIU I am associating the different
> kernel namespaces with it and not different pre-dumps. At least that is
> how I am understanding your namespace/pre-dump implementation.

Okey, the 'namespace' term was a bad choice,  I didn't know it was
used somewhere else. In this context, a 'namespace' is a tag representing
the creator of an image file. For example: a) pre-dump of process X will
create pages-1.img; b) dump of process X will also create pages-1.img. 

With disk-backed CRIU (not using image-cache/proxy) you know which pages-1.img
came from the pre-dump and which came from the dump (since you use different 
working dirs).

To solve this problem inside the image-cache/proxy, I tag each image with the
working directory of the process that created it. For example: a) pre-dump of
process X will send the image with name:pages-1.img and 
namespace:/home/pre-dump-working-dir, where the namespace is the user provided 
working dir. Using the name+namespace I have an unique ID for each image.

I am glad to accept suggestions to make the code more clear.

> 
> Besides that I am looking forward to the image-cache/image-proxy
> functionality. That sounds really useful.

Great!

> 
> 		Adrian


-- 
Rodrigo Bruno <rbruno at gsd.inesc-id.pt>