[CRIU] [GSoC 2019] Interested in CRIU project

[Pavel Emelianov]

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?

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

-- Pavel