inet.af/netstack

netstack

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.

UPDATE

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.

Why?

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.

Contributing

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 googletree uses Bazel, not the cmd/go Go 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

License

Same as gVisor.