[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