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

[Ruslan Kuprieiev]

Hi Stephane,

On 06/30/2015 10:27 PM, Stéphane Graber wrote:
> 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.

Ok, I'll send a patch  right after I'll fix libcriu to be able to just pass
libcriu's options structure.

Thanks.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20150701/25cb3914/attachment.html>