[CRIU] CRIU 2.0

[Pavel Emelyanov]

On 12/15/2015 03:11 AM, Tycho Andersen wrote:
> Hi Pavel,
> 
> On Mon, Dec 14, 2015 at 01:09:06PM +0300, Pavel Emelyanov wrote:
>> Hi,
>>
>> Right now in criu we have at least two parts that are useful by themselves
>> and sometimes people ask for those as separate libraries. The parts are -- 
>> the implementation of infecting tasks with random blob (parasite) and TCP
>> checkpoint-restore code.
>>
>> So by the next release I propose to re-suffle the CRIU source tree and make
>> effectively three distinguished components under the same name -- the criu 
>> tool itself, the infecting library and tool and the TCP CR library. For the
>> infecting library we've once tried to pull this into a separate project 
>> called 'compel' (https://github.com/xemul/compel), with core library, helper 
>> libs and CLI tool, but with no luck -- it was so basic to CRIU that patching
>> them independently was too complex. Hopefully maintaining compel in the criu
>> tree at least for the first time would make this finally happen.
>>
>> And, while tossing the code around, it would also make sense to make some
>> order in the source tree at least putting CRIT into its own subdir, putting
>> zdtm tests into one place and moving the legacy tests aside.
> 
> And potentially removing some levels necessary to cd? I've never
> understood what zdtm/live/static is :)

Well, yes, nice catch. There was an attempt to separate static tests, that
do not move while being checkpoint-restored from those that work constantly.
And the 3rd type that blocks the C/R.

>> With all these changes I think it would make sense to do tag criu 2.0 :)
>>
>>
>> As the initial suggestion on the code structure and names I have:
>>
>> crtools/        for the existing criu code
>>    pycriu/      for python bindings
>>    lib/         for C library
>>    go/          for go binding (if we ever have one)
> 
> For this, if I were doing it myself, I'd have it as
> 
> criu/
>   cr-restore.c
>   protobuf/
>   ...
> 
> lib/
>   pycriu/
>   go/
>   c/
> 
> Since the libraries are not dependent on anything besides
> protobuf/rpc.proto (which we could keep in / and symlink or something)

OK, makes sense.

> I know before we mentioned changing the release schedule slightly;
> when were you thinking of tagging 2.0?

There gonna be another e-mail about it from me some time soon :)

>> libsockcr/      for TCP checkpoint-restore
>>
>> The output is libsockcr.so (and libsockcr.a)
> 
> A cute name (for Americans, at least) for this would be libsoccr.so,
> as a play on "soccer". That may be a bad idea though :)

Name audit from speakers of different languages is always good... There
should be some service doing this so that stuff like pidora or runc get
noticed in advance :)

-- Pavel