[lxc-devel] [PATCH] lxc-checkpoint: add pre-checkpoint

[Stéphane Graber]

On Tue, Jun 30, 2015 at 08:37:11AM -0600, Tycho Andersen wrote:
> On Tue, Jun 30, 2015 at 05:09:40PM +0300, Ruslan Kuprieiev wrote:
> > Hi Tycho,
> > 
> > On 06/30/2015 04:50 PM, Tycho Andersen wrote:
> > >Hey Ruslan,
> > >
> > >On Fri, Jun 26, 2015 at 11:24:32AM +0300, Ruslan Kuprieiev wrote:
> > >>Drop this one, please.
> > >I'm assuming you're probably going to send another version at some
> > >point, a question below.
> > >
> > >>>diff --git a/src/lxc/lxccontainer.h b/src/lxc/lxccontainer.h
> > >>>index d60e19a..1faded2 100644
> > >>>--- a/src/lxc/lxccontainer.h
> > >>>+++ b/src/lxc/lxccontainer.h
> > >>>@@ -773,7 +773,7 @@ struct lxc_container {
> > >>>  	 * \return \c true on success, else \c false.
> > >>>  	 * present at compile time).
> > >>>  	 */
> > >>>-	bool (*checkpoint)(struct lxc_container *c, char *directory, bool stop, bool verbose);
> > >>>+	bool (*checkpoint)(struct lxc_container *c, char *directory, char *prev_dir, bool stop, bool verbose);
> > >Here we're making an ABI change, and I'm not sure what the protocol in
> > >LXC for this (Stéphane or Serge can tell us I'm sure :). Whatever the
> > >case, we'll have to do some tap dancing here. It may (?) be worth
> > >turning this into an argument struct with version information to avoid
> > >this in the future, depending on how we solve this.
> > 
> > Neither am I happy about changing abi in such a way. That's one of the
> > reasons
> > why I asked to drop this patch for now =).
> > 
> > But looks like there is no other way but to change abi, as current arguments
> > for do_checkpoint do not satisfy our needs, if we want teach lxc-checkpoint
> > to do anything more advanced than just plain dump.
> 
> Yes, unfortunately I didn't do a good job of future proofing the API.

Right, so for LXC, modifying or removing an existing symbol isn't an
option until LXC 2.0 and liblxc2.

Until then, the best you can do is introduce a new symbol with the new
ABI and turn the old one into a backward compatibility one.

> 
> > Struct for options would be nice, I agree. But I actually thought about
> > using
> > libcriu's options to set\get options without adding any additional mediator
> > structures. Though, It would require modifying libcriu to actually return
> > void *
> > with options in it as well as adding criu_get-ers and fixing criu_set-ers to
> > be
> > able to pass options struct as an argument.
> 
> I see, and then just porting liblxc to use libcriu and allowing users
> to pass in a pre-initialized opaque criu options pointer? That also
> seems reasonable to me.
> 
> FWIW, I think the only way to avoid an ABI break here would be to
> implement ->checkpoint2(), which kind of sucks. I'm not sure how much
> work it is to bump the soname, but maybe that could be a temporary
> solution. If it's not too hard, then we could do the above now and not
> have to deal with it again.
> 
> Tycho
> 
> > >Anyway, I just thought I'd get the discussion started.
> > >
> > >Tycho
> > >_______________________________________________
> > >lxc-devel mailing list
> > >lxc-devel at lists.linuxcontainers.org
> > >http://lists.linuxcontainers.org/listinfo/lxc-devel
> > 
> > _______________________________________________
> > lxc-devel mailing list
> > lxc-devel at lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-devel
> _______________________________________________
> lxc-devel mailing list
> lxc-devel at lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-devel

-- 
Stéphane Graber
Ubuntu developer
http://www.ubuntu.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150630/9c9c3d21/attachment.sig>