[CRIU] [GSoC 2019] Interested in CRIU project

[James Cui]

So the conclusion is to put code into go-criu and reimplements
functionality in criu/lib/py right?
Also are there any code that I'd better to look at in go-criu to prepare
this project?

On Wed, Mar 13, 2019 at 11:02 AM Pavel Emelianov <xemul at virtuozzo.com>
wrote:

> On 3/13/19 7:51 PM, Adrian Reber wrote:
> > On Wed, Mar 13, 2019 at 02:56:52PM +0000, Pavel Emelianov wrote:
> >> On 3/13/19 5:44 PM, Adrian Reber wrote:
> >>> On Wed, Mar 13, 2019 at 02:26:27PM +0000, Pavel Emelianov wrote:
> >>>> On 3/13/19 11:10 AM, Adrian Reber wrote:
> >>>>> On Tue, Mar 12, 2019 at 09:14:47PM -0700, James Cui wrote:
> >>>>>> Thanks Pavel and Adrian for the answers!
> >>>>>> One question though. For the go implementation of CRIT, will it
> live in the
> >>>>>> same repo of CRIU or some other repo (For example, I create my own
> repo in
> >>>>>> github)?
> >>>>>> I asked because I saw a repo called go-CRIU, is this the place all
> go
> >>>>>> implementation should be?
> >>>>>
> >>>>> I think it should live in the go-criu repository. I think it should
> be a
> >>>>> library which can be used by the new CRIT implementation but also be
> >>>>> used by other projects which need to read or write CRIU image files.
> >>>>
> >>>> Now a question from me :) Do we want to continue maintaining both criu
> >>>> libs -- go anf py -- or make py version call the go one?
> >>>
> >>> Good question. Not sure.
> >>>
> >>> I think we need a go version at some point, so it makes sense to have
> >>> it. For LXD precopy migration I already implemented some image file
> >>> reading into LXD and it would make sense to maintain the image file
> >>> manipulation for Go in one place. But if it is maintained in the
> go-criu
> >>> repository it will not be automatically available for anyone checking
> >>> out CRIU. Which currently is really nice, you check out CRIU and you
> >>> have (python) CRIT for debugging.
> >>
> >> Absolutely.
> >>
> >>> On the other hand if we have Go CRIT, which is also embedded into other
> >>> projects, it does not make sense to keep the Python CRIT libraries.
> >>
> >> But the CRIT tool itself -- should it also become golang-written in
> this case?
> >
> > Would make sense.
>
> OK
>
> >>> I guess we wait if it works as good as the Python version or better and
> >>> decide then how we want to use it.
> >>
> >> Yes, but the reason I'm asking is the "anonymize image files" task for
> this
> >> GSoC. I guess it will be done on the py-crit basis, so we'll have two
> not equal
> >> sets of functionalities in py vs go right at once :)
> >
> > So, hmm, it seems we did not coordinate our GSoC topics.
>
> ^_^
>
> > Right now I
> > would say, let's first wait which of our topics are people interested in
>
> https://criu.org/GSoC19_Students_Requests
>
> and we have both -- go-images and anon-images covered.
>
> > and once we actually have results, we need to figure out which way we
> > want to go. Maybe the Go part is only a library and CRIT stays python
> > based, or maybe add the "anonymize image files" also to the Go
> > implementation.
> >
> > Not really sure how to best handle this. Any other ideas from you?
>
> I agree with your proposal to start going with what we have and do
> anonymizer
> in py and go-images from scratch for your needs first and see how it will
> go.
>
> -- Pavel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20190314/f55fcf71/attachment.html>