[CRIU] CRIU 2.0

[Tycho Andersen]

On Tue, Dec 15, 2015 at 02:37:48PM +0300, Pavel Emelyanov wrote:
> 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.

Ok, sounds good. Dropping this would be handy :)

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

Sounds good :)

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

:D nothing like that in here, at least.

Tycho