/cc @mikioh

To access additional system calls, as of Go 1.9, net.Conns implement https://golang.org/pkg/syscall/#Conn, which lets you get a syscall.RawConn, which lets you use the fd directly. So maybe exposing internal/socket is not needed?

Yes but internal/socket has exposes recvmmsg and recvmsg with a Go interface. syscall.RawConn requires that I do syscalls directly myself, which I'd like to avoid.

You can wrap it up into a nice Go package on GitHub, though, and then use that from your pretty code. internal/socket was never written for external consumption.

Yes, I understand that. But I think internal/socket has been erroneously concealed from external use by assuming users go through the ipv4/ipv6 packages (unless I missed something). A Go wrapper to recvmsg and recvmmsg should be exposed somewhere, why not here, where the current API is precisely what is needed. If I copy this package to use it elsewhere, I'll risk drifting from the semi-official state of x/net, which evolves to fit the syscall story of the day.

Note there are other socket domains that support msg oriented syscalls, it seems like an appropriate abstraction to expose.

Was it not already exposed once when Berkely baked it into UNIX? How many generations will endure its abstract fragrance?

syscall.RawConn requires that I do syscalls directly myself, which I'd like to avoid.

It sounds like RawConn lets you do what you need. I understand you wish it was nicer, but we don't want to commit to any of the API in internal/socket.

The same as #17930, I'm personally fine with having a UDP-specific package in x/net repository. Also fine with considering a comprehensive way; constructing a bit more modern transport layer API such as Post Sockets.