inetaf / netstack Goto Github PK

I realise that this library is still usable without being a module directly, but I imagine there's no reason to avoid adding a go.mod file either?

One good reason to add a go.mod file is that one can use commands like go build, go list, and so on. Another is UX: it's not entirely clear that I'm meant to import this as inet.af/netstack rather than github.com/inetaf/netstack if I don't see a go.mod saying as much.

Upstream fix a memory leak problem on Fix PacketBuffer memory leak.

gVisor not fully resolved this memory leak, waiting for them to make a full fix

Maybe this repository should be synced upstream?

As of 7585b01 this repository seems to claim it is no longer required, in favour of using the tcpip package from github.com/google/gvisor or gvisor.dev/gvisor directly (claiming that Go 1.17 fixes the lazy loading at least). However, I have been completely unable to move across to upstream.

Trying to substitute the inet.af/netstack/tcpip imports in my own project with gvisor.dev/gvisor/pkg/tcpip results in catastrophic build errors on seemingly all recent commits. Dozens of issues — go mod tidy fails for various reasons, go test ./... reports build errors and my own application fails to build too. I've tried this with various recent commits, including with the release-20211115.0 tag that this repository seemed to last import. Trying this on a Linux machine instead of a Mac produces some different results but still unusable. Both with Go 1.17.

However, release-20211115.0 of inet.af/netstack works perfectly, even on macOS.

With that in mind, is this repository really no longer required? It seems like upstream is totally unusable somehow, and yet none of these issues manifest with inet.af/netstack — this fork works flawlessly. It seems like this repository still very much solves a problem in making netstack usable in isolation.

Am I missing something obvious here?