[CRIU] [GSoC 2019] Interested in CRIU project

Pavel Emelianov xemul at virtuozzo.com
Fri Mar 15 16:40:02 MSK 2019


On 3/15/19 9:20 AM, James Cui wrote:
> So the conclusion is to put code into go-criu and reimplements functionality in criu/lib/py right?

Well, hopefully Adrian supports me on this -- yes put the code into go-criu, but keep the
existing py code to let other people work on the anonymizing images task. If we find out
we have time in summer to move even the new code -- we'll slightly correct the plan.

> Also are there any code that I'd better to look at in go-criu to prepare this project?

Adrian?

-- Pavel

> On Wed, Mar 13, 2019 at 11:02 AM Pavel Emelianov <xemul at virtuozzo.com <mailto: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
> 




More information about the CRIU mailing list