libcontainer/utils: cross-platform use of unix/syscall

[vbatts]

unix.WaitStatus is unix only ... syscall.WaitStatus exists on more platforms

Signed-off-by: Vincent Batts vbatts@hashbangbash.com

[cyphar]

We've been slowly switching runc to use golang.org/x/sys/unix over syscall because it is getting improvements and is better maintained than syscall (syscall has the Go stability guarantee attached which means that it cannot really be improved). Since runc only is meant to work on Linux, this shouldn't be an issue.

[frezbo]

BTW this topic being aside, what does docker uses for windows containers as the runtime? I thought it also used runc

[cyphar]

Docker uses VMs under the hood using HyperV (though I believe in newer versions hcsshim will actually create a "container" on Windows -- which is a new HyperV concept apparently). MacOS also uses VMs with xhyve.

You still can't run runc underneath their Linux compatiblity project (though you can get quite close -- they have yet to implement mount propagation and a few other Linux features needed to use runc). And unlike the FreeBSD or illumos Linux compatibility projects, I believe (though can't verify since I don't use Windows) that you couldn't use the above to run Windows programs inside a runc container on Windows since WSL has some odd restrictions on where Windows programs must exist in order to execute them.

EDIT: Sorry, they do appear to have cross-compatibility now but it's not clear to me how this interoperability works and whether you could actually us it from within a runc container (they talk about the "windows $PATH" which leads me to believe they still require Windows binaries to be on the Windows filesystem).

[vbatts]

@cyphar i understand that, but that is the benefit of a stdlib that may have multi-platform presence. It gets uglier to spread these calls out to their on platform files. :-\

[cyphar]

The problem is that syscall is not as well-maintained as golang.org/x/sys -- because Go as its backwards compatibility guarantees that make it hard to change incorrectly designed APIs. But ultimately I don't have a strong opinion on a ~6 line patch so ... idk.

[vbatts]

updated. PTAL.

[vbatts]

changed the title as this is not wholly switching back to syscall

[vbatts]

bump