[CRIU] [GSoC 2019] Interested in CRIU project

Pavel Emelianov xemul at virtuozzo.com
Wed Mar 13 21:02:50 MSK 2019


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