Replace uses of syscall.EPOLLET with unix.EPOLLET

[mundaym]

syscall.EPOLLET has incorrectly been generated as a negative number on 386/amd64/arm. Due to the Go 1 guarantee it is frozen and cannot be fixed (golang/go#5328). This leads to workarounds where EPOLLET is negated before it is used. Unfortunately on other platforms it has the correct, positive, value making the negation incorrect.

Can unix.EPOLLET be used instead (https://godoc.org/golang.org/x/sys/unix#pkg-constants)? It is correct on all platforms.

(@ydjainopensource ran into this while investigating #79)

[ghost]

syscall.EPOLLET is used at 3 places. However, there is a comment which acknowledges this issue here which makes me question whether the unix pkg was not used on purpose.Can anybody confirm before I send a PR?

I am able to compile if I change it to use unix.

[prattmic]

That comment was written before we used the unix package anywhere in gVisor, which is why it isn't used there. Switching to the unix package is fine.

That said, there is an opportunity for a bit more cleanup here.

TL;DR for below, use the unix package here and the linux package here and here. You'll need to add EPOLLET to the linux package.

We use syscall constants like EPOLLET in two different contexts.

1. Sentry-host interactions.

These are cases where the sentry is making system calls to the host Linux kernel to perform some operation. That is the case here. The sentry is making epoll syscalls to the host, so we use the syscall (or unix) package.

If there were a port of gVisor to another host OS, e.g., FreeBSD, we want to use the appropriate syscall constants for FreeBSD¹. The syscall and unix packages do this automatically.

2. App-sentry interactions.

These are cases where the sandboxed app is making a syscall that the sentry is handling. That is the case here. If we port gVisor to another host OS, we're still running Linux applications inside the sandbox, so using the syscall or unix package is incorrect, as they provide values for the host OS.

For these cases, we use the linux package, which is very similar to syscall/unix, but always provides the values for Linux.

The final use of EPOLLET is an odd edge case inside gVisor, but I believe those protos always expect Linux flags, so IMO it should be using the linux package.

The existence of a gVisor port to a non-Linux host OS is theoretical at this point, so we have not gone through and replaced all instances of case 2 with the linux package, but we've been slowly converting them as we refactor or other issues like this arise.

¹ Note that epoll isn't a great example here because it is Linux-specific. A better example would be open flags like syscall.O_RDWR, which are defined on multiple OSes, but may have different values.

[nlacasse]

We no longer use syscall.EPOLLET, but use linux and unix packages as appropriate.