[CRIU] [GSoC 2019] Interested in CRIU project
Adrian Reber
areber at redhat.com
Wed Mar 13 19:51:20 MSK 2019
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.
> > 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
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?
Adrian
More information about the CRIU
mailing list