inet.af/netstack@v0.0.0-20220214151720-7585b01ddccf/README.md (about)

     1  # netstack
     2  
     3  This was a "fork" of https://github.com/google/gvisor, extracting out
     4  just the "netstack" networking bits, which previously were
     5  self-contained at https://github.com/google/netstack.
     6  
     7  ## UPDATE
     8  
     9  This repo is no longer maintained. As of Go 1.17 and its [lazy module
    10  loading](https://go.dev/ref/mod#lazy-loading) we no longer need it, so we now
    11  just use upstream gVisor directly.
    12  
    13  ## Why?
    14  
    15  Because [gVisor's `go.mod` is gigantic](https://github.com/google/gvisor/blob/go/go.mod)
    16  and causes problems to people trying to use it as a library.
    17  
    18  Arguably Go's tooling is also somewhat to blame: Go doesn't make it
    19  easy (or even possible) to use a subset (a few packages) out of a mega
    20  module like gVisor without getting impacted by otherwise-unrelated
    21  requirements of that dependent module. (Update: as of Go 1.17, this
    22  appears to be fixed; see UPDATE above)
    23  
    24  Specifically, [Tailscale](https://github.com/tailscale/tailscale)
    25  wanted to use gVisor's `tcpip` networking packages, which worked fine for a
    26  while, but then one day we bumped our gVisor version to pull in a bug fix we
    27  needed (from the networking-related part of gVisor), and that ended up
    28  making us pull in new conflicting versions of `etcd`. Why? Because
    29  [somewhere in that
    30  `go.mod`](https://github.com/google/gvisor/blob/go/go.mod) Docker or
    31  `grpc` or Kubernetes or whatever depended on etcd somehow. Who knows. We
    32  spent too long trying to fix it and gave up.
    33  
    34  Our fix is this repo, pulling netstack out of gvisor like it used to be,
    35  with [a small `go.mod`](https://github.com/inetaf/netstack/blob/main/go.mod).
    36  
    37  ## Contributing
    38  
    39  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:
    40  
    41  * humans maintain gVisor inside Google's internal monorepo (let's call it `googletree`)
    42  * some scripts inside Google export `//googletree/gvisor/...` out into GitHub occasionally
    43  * oh, but `googletree` uses [Bazel](https://bazel.build/), not the `cmd/go` Go tool
    44  * so some other scripts rearrange the GitHub repo into the [gVisor "go" branch](https://github.com/google/gvisor/tree/go) (https://github.com/google/gvisor/#using-go-get)
    45  * 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
    46  
    47  ## License
    48  
    49  Same as gVisor.
    50  
    51  
    52  
    53  
    54  
    55  
    56  
    57