[CRIU] CRIU and GO

[Andrei Vagin]

On Wed, Oct 03, 2018 at 08:12:04AM +0200, Adrian Reber wrote:
> On Tue, Oct 02, 2018 at 07:18:21PM -0700, Andrei Vagin wrote:
> > On Tue, Oct 02, 2018 at 08:17:01AM +0200, Adrian Reber wrote:
> > > Hello Andrei,
> > > 
> > > I am currently trying to add checkpoint/restore support to podman:
> > > 
> > > https://github.com/containers/libpod/pull/469
> > > 
> > > and I hope it will soon be merged. As I need at least CRIU 3.11 for
> > > podman I would like to include a version check into podman.
> > > 
> > > As we already have a version check in GO in runc I was first looking at
> > > the runc code but then I remembered the Pavel's CRIU go interface in
> > > lib/go/.
> > > 
> > > So for podman I tried to vendor-in github.com/checkpoint-restore/criu
> > > and started to wonder if we might want to have an independent GO
> > > binding, because right now most of the vendor-in'd code is C code and
> > > tests and not much GO code.
> > 
> > Is it impossible to vendor only github.com/checkpoint-restore/criu/lib/go/src/criu?
> 
> Hmm, the tool used to manage the vendoring (vndr) keeps all the .c files
> around. If manually managing the vendor tree it would probably be
> possible, but using the tool it is not. But I hardly have any
> experience how to manage a GO project. Right now I get:
> 
> $ du -hs vendor/github.com/checkpoint-restore/criu
> 5.8M	vendor/github.com/checkpoint-restore/criu
> 
> It just seems easier to detect the CRIU GO bindings if they would be a
> separate repository, especially as it probably can live with a
> completely different and much slower release schedule. Most changes
> to CRIU are not necessarily necessary in the GO bindings. Right now the
> GO code is buried in a lot of C code which the vndr tool does not delete
> as it could be a cgo file.
> 
> > > So instead of including 'github.com/checkpoint-restore/criu/lib/go/src/criu'
> > > we could have something like 'github.com/checkpoint-restore/go-criu' ?
> > > 
> > > What do you say? Would it make sense to have an independent go binding
> > > for CRIU? Once it works we could start to also use it in runc...
> 
> The main idea was to have a canonical location for the go bindings which
> is easy to detect and switch runc to using it once it exists. I would
> like to use it in podman right now and the vendor/github.com tree is
> around 20MB of which 5MB is CRIU. It basically is only a tool problem
> (vndr), but it probably is more difficult to change the tool, then
> provide CRIU go bindings separately.

Ok. All these sound reasonable. I don't have objections about a new repo.

Thanks,
Andrei

> 
> 		Adrian