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