[CRIU] rewriting images via criu (or crit?)

Ruslan Kuprieiev kupruser at gmail.com
Mon Oct 27 09:04:39 PDT 2014


On 27.10.2014 17:32, Tycho Andersen wrote:
> On Mon, Oct 27, 2014 at 05:10:33PM +0200, Ruslan Kuprieiev wrote:
>> Hi all,
>>
>> I was recently thinking about converting/modifying images and i want to
>> share some of my thoughts.
>> For now I see 4 main ways:
>>
>> 1) Use existing patch set for crit written in python.
>> Pros:
>>      1. Already works.
>>      2. Python project is easy to support.
>>      3. Adding xpath-like language for modifying images should be easy in
>> Python.
>>      4. All needed dependencies are available in (any?) repo.
>> Cons:
>>      1. Performance(maybe we could use Cython to make it better?).
>>
>> 2) Rewrite crit in C
>> Pros:
>>      1. Performance.
>> Cons:
>>      1. C project is hard to support.
>>      3. Adding xpath-like language for modifying images is not as easy as in
>> Python.
>>      4. Requires protobuf-c-text, which is quite new and isn't available in
>> repos.
>>
>> 3) Add crit functionality to criu ("criu convert", "criu modify").
>> Pros:
>>      1. Performance
>>      2. Allows us to reuse a bunch of existing code.
>>      3. Having such tool shipped along with "criu show" looks like a nice
>> feature.
>>      4. We can easily teach criu how to use images in text format, which
>> seems
>>          quite handy.
>> Cons:
>>      1. criu is already complex enough and adding more stuff might be too
>> much,
>>          especially xpath-like language engine.
>>      2. Hard to support.
>>      3. Requires protobuf-c-text, which is quite new and isn't available in
>> repos.
>>      4. Requires heavy patching to existing code.
>>
>> 4) Use 1), but for _high-speed_ image modification use criu plugins and
>> hooks
>>      to modify images on restore.
>> Pros:
>>      1. Performance.
>>      2. No heavy patching.
>> Cons:
>>      Can't see any.
>>
>> I prefer 4) because it seems like a good compromise.
>> What do you guys think?
> Does that mean we'd need to expose all the protobuf headers? Will
> users then need to link against libprotobuf?

We would need to expose proto files with crit anyway(just the way we are
shipping rpc.proto), so exposing protobuf headers shouldn't be a problem.
Plugin indeed should be linked against libprotobuf-c. Is that a problem?

I mean, yes, plugin isn't very flexible tool, but it should be faster 
than calling
a separate tool to modify image. For flexibility one could use crit 
written in python.

Could you explain your needs again, please?

Thanks,
Ruslan

> Tycho



More information about the CRIU mailing list