use https://github.com/usbarmory/go-net/pull/1 refactor

[soypat]

No description provided.

[abarisani]

Please do not remove the build tag (essential to reduce binary size for users not needing network) and do not include a replace line in go.mod.

Also, callers of any go-net refactor should not be aware or whether gvisor or a different stack is used. So I have issues with newDefaultStack()

[soypat]

Please do not remove the build tag

Build tag was automatically formatted to be on the first line of the file so should still work. If you need the license to be on the top I can disable my autoformatter for the file.

replace line in go.mod

Strictly there since without it or without a go.work file this PR is still in need of a merge on go-net side. The replace line serves as this reminder and also to be able to compile go-boot and test it. I'm not familiar with how usbarmory compiles PRs which require unmerged work but I'd gladly work within the methodology of the organization. The replace line would not make it into the final work.

callers of any go-net refactor should not be aware or whether gvisor or a different stack

Absolutely not. As of this PR callers will not have any exposed gvisor API. newDefaultStack is unexported. After adding lneto I imagine newDefaultStack would be moved to its own file with a net, net-gvisor or net-lneto build tag. At no point should users have access to API that leaks the abstraction

[abarisani]

Thanks for clarifying, what I meant with the gvisor API is that I see gnet.NewGVisorStack(1) within the go-boot PR.

Ideally I'd like go-net users, and therefore go-boot users, to build the same code with either gvisor or lneto, this in mind should entail that gnet.NewGVisorStack(1) should not be called in go-boot, am I making sense?

[soypat]

OK, thanks for expanding on your concerns- I think I follow now. I'll detail my reasoning for this design below.

build the same code

I understand your concern stems from sharing as much code regardless of stack used. We don't want to duplicate the code maintained when adding a new networking stack

I also note you raise a valid point on gvisor being called within go-boot, which goes against a stack-independent approach. However note that if you do not call to gvisor here you'll need to call gvisor in go-net.

Thus, it sounds tempting to have the gvisor call be hidden behind a go-net API since if we implement it there then there will be less code duplication since all go-net users will benefit from this shared API, be it a single line of code.

That said, if I study this from a design perspective it feels off to include this call in go-net because it would suppose a default networking stack for all users of go-net. go-net package has sought to form an abstraction of the networking hardware and software and has done so succesfully by exposing no concrete gvisor nor NIC driver API on its interfaces. To expose a default stack on go-net is to define build tags for go-net, a package which is specifically designed to be architecture/OS independent.

Furthermore, if we define a default stack in go-net we'd be stuck with that stack as default to not break users in future. That stack would almost certainly be gvisor since it is proven. Meanwhile lneto is closing in on gvisor's functionality and would surpass gvisor performance in terms of memory usage and likely CPU usage as well.

I've added net_gvisor.go and net_lneto.go to illustrate how build tags in go-boot would look like at the file level. in this case gvisor would be the default stack since net-lneto is not a build tag that would be defined unless lneto stack were desired.

[abarisani]

Right now gvisor is the more tested implementation for our code base and I am not willing to switch away overnight.

I would be happy to always force a build tag in go-net (meaning that there is no default) and transition from gvisor to lneto gradually in all our unikernels.

go-boot needs a NET variable anyway so I will change it from integer to the actual build tag.

This feels a neutral and gradual approach for all parties imho.

[soypat]

Alright- will implement build tags on go-net side