This was a "fork" of https://github.com/google/gvisor, extracting out just the "netstack" networking bits, which previously were self-contained at https://github.com/google/netstack.
This repo is no longer maintained. As of Go 1.17 and its lazy module loading we no longer need it, so we now just use upstream gVisor directly.
Because gVisor's go.mod is gigantic
and causes problems to people trying to use it as a library.
Arguably Go's tooling is also somewhat to blame: Go doesn't make it easy (or even possible) to use a subset (a few packages) out of a mega module like gVisor without getting impacted by otherwise-unrelated requirements of that dependent module. (Update: as of Go 1.17, this appears to be fixed; see UPDATE above)
Specifically, Tailscale
wanted to use gVisor's tcpip networking packages, which worked fine for a
while, but then one day we bumped our gVisor version to pull in a bug fix we
needed (from the networking-related part of gVisor), and that ended up
making us pull in new conflicting versions of etcd. Why? Because
somewhere in that
go.mod Docker or
grpc or Kubernetes or whatever depended on etcd somehow. Who knows. We
spent too long trying to fix it and gave up.
Our fix is this repo, pulling netstack out of gvisor like it used to be,
with a small go.mod.
We don't accept contributions. This repo isn't human-maintained. It's synced from gVisor's "go" branch. In fact, the flow looks like:
- humans maintain gVisor inside Google's internal monorepo (let's call it
googletree) - some scripts inside Google export
//googletree/gvisor/...out into GitHub occasionally - oh, but
googletreeuses Bazel, not thecmd/goGo tool - so some other scripts rearrange the GitHub repo into the gVisor "go" branch (https://github.com/google/gvisor/#using-go-get)
- some of our scripts then take that "go" rearrangement tree and delete all the Linux and Docker and container stuff, leaving behind only the networking stuff
Same as gVisor.