Golang x/net/netlink, vendor/golang.org/x/net/netlink: new package

I propose to have a x/net/netlink package and vendor it to the standard library for maintenance purposes.

Netlink is a Linux-specific service for manipulating networking facilities inside the kernel. Fortunately, unlike routing messages and sockets on BSD variants, it doesn't have much ABI incompatibility between major kernel releases, but its complexity like TLV-in-AVP-in-TLV data representation could be a root cause of issues like #18714, #16681. So I think it's better to have and maintain a small separated package like the existing x/net/route package.

The exposed API would be like the following: - minimal netlink message types mostly for the use of standard library, - minimal netlink message parsers mostly for the use of standard library, - both types and parsers are ABI agnostic and safe from potential misaligned memory access.

Thoughts?

Comment From: bradfitz

What in the the standard library needs it?

/cc @mdlayher

Comment From: mikioh

As far as I can tell, the net package of standard library requires at least a) fetching netlink routing information base, b) parsing netlink routing messages related to on-link adjacencies for now.

Comment From: bradfitz

As far as I can tell, the net package of standard library requires at least a) fetching netlink routing information base, b) parsing netlink routing messages related to on-link adjacencies for now.

What bug is that?

Which existing functions/methods don't work?

Got a sample program?

Comment From: bradfitz

In other words, this proposal is a solution but you haven't yet sufficiently identified any problem. We don't accept proposals if there's not a problem.

Comment From: mikioh

a solution

Yup, I'm guessing that @mdlayher has another perspective on this stuff because he poked me in #10565; once we make external socket and its addresses work together with the net package.

Comment From: mdlayher

I've got a netlink package that does its best to just focus on pure netlink: not conflating it with rtnetlink, genetlink, etc. I would be happy to contribute parts or all of it to become x/net/netlink. [1]

That being said, because of #10565, I don't have an easy way of configuring timeouts without doing all of the epoll work myself. This isn't such a big deal because netlink is Linux only, but I'd be happy to see that issue solved for the sake of other sockets packages which may attempt to provide some cross platform functionality. [2]

As for the original point, I think it could make sense to provide a high quality netlink package in x/net that could be useful both inside and outside the standard library.

The biggest potential problem I can think of with the existing netlink functionality in syscall is that netlink does not seem to cooperate with Go's scheduler moving goroutines between threads. This is a problem I'd also like to tackle in my own package, but have not yet had the chance to do so.

I'm happy to help make this happen if there is a consensus that this proposal should move forward.

[1] https://github.com/mdlayher/netlink [2] https://github.com/mdlayher/raw

Comment From: mdlayher

More info on my concurrency woes with netlink and Go: http://lists.infradead.org/pipermail/libnl/2017-February/002293.html

Comment From: mdlayher

One more thing worth noting: I haven't seen any concurrency problems with the netlink usage in the standard library. I can't say for sure if it could be an issue or not.

Perhaps @mikioh has other problems in mind?

Comment From: bradfitz

Could somebody please succinctly state the problem?

Comment From: mdlayher

Would love to hear if you had any specific pain points in mind, @mikioh .

Comment From: rsc

Having x/net/netlink seems fine. Vendoring it into stdlib seems less fine: x/net grows faster than most of the stnadard library, and I'd rather not give that growth a route into the stdlib. What specifically needs fixing in the standard library?

Comment From: rsc

No answer to "what specifically need fixing in the standard library?" If nothing does, then let's say we'll add a x/net/netlink but not vendor it into the standard library.