[CRIU] CRIU 2.0

[Tycho Andersen]

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 :)

> 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)

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

> 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 :)

Anyway, my advice is worth what you paid for it.

Tycho