What in the the standard library needs it?

/cc @mdlayher

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.

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?

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.

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.

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

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

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?

Could somebody please succinctly state the problem?

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

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?

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.

/cc @mikioh @mdlayher

Accepted for x/net/netlink (only).