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. > 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@lists.linuxcontainers.org > >http://lists.linuxcontainers.org/listinfo/lxc-devel > > _______________________________________________ > lxc-devel mailing list > lxc-devel@lists.linuxcontainers.org > http://lists.linuxcontainers.org/listinfo/lxc-devel _______________________________________________ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel