x/sys/unix: add RecvmsgBuffers and SendmsgBuffers

[ianlancetaylor]

The golang.org/x/sys/unix package was created with Recvmsg and Sendmsg functions copied from the ones in the syscall package. Those date back to https://go.dev/cl/2331044, committed in 2010 for #1101. Unfortunately, those Recvmsg and Sendmsg functions do not correspond to the recvmsg and sendmsg system calls. The system calls take a pointer to a Msghdr struct. The Recvmsg and Sendmsg functions build a Msghdr instance, but they don't support the full functionality of recvmsg and sendmsg: they don't permit setting up the scatter/gather array.

Working directly with a Msghdr is awkward for the x/sys/unix routines. It seems better to provide some translation for the socket address. Still, we should provide access to the scatter/gather array. I propose the following:

// RecvmsgBufs receives a message from a socket using the recvmsg system call.
// The flags are passed to recvmsg. Any non-control data read is scattered into bufs. The results are:
//  - n is the number of non-control data read into bufs
//  - oobn is the number of control data read into oob; this may be interpreted using [ParseSocketControlMessage]
//  - recvflags is flags returned by recvmsg
//  - from is the address of the sender
func RecvmsgBufs(fd int, bufs [][]byte, oob []byte, flags int) (n, oobn int, recvflags int, from Sockaddr, err error)

// SendmsgBufs sends a message on a socket to an address using the sendmsg system call.
// The flags are passed to sendmsg. Any non-control data writen is gathered from bufs.
// The function returns the number of bytes written to the socket.
func SendmsgBufs(fd int, bufs [][]byte, oob []byte, to Sockaddr, flags int) (int, error)

Part of the goal of these functions is to simply the golang.org/x/net/internal/socket package, which currently reaches into the syscall package for syscall.recvmsg and syscall.sendmsg.

CC @tklauser @mdlayher

[tklauser]

I agree, these seem like useful functions to have in x/sys/unix.

[jech]

Minor nit: I suggest renaming oob []byte to control []byte, so that the function is easier to correlate with the manual page, and the ParseSocketControlMessage is easier to find.

[mdlayher]

I think the general historical trend has been to mimic the C API names.

SGTM on adding these functions.

[rsc]

Since we spelled out net.Buffers for a [][]byte, should we call this Buffers instead of Bufs too?

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[jech]

Since we spelled out net.Buffers for a [][]byte, should we call this Buffers instead of Bufs too?

I could be wrong, but it is my understanding that the reason why net.Buffers is a named type is that it has two methods attached (it implements Reader and WriterTo). I don't think that's required or even desirable here.

[ianlancetaylor]

We're not going to actually use net.Buffers here. The question is whether the new functions should be named RecvmsgBuffers and SendmsgBuffers.

[jech]

Thanks for the clarification.

[rsc]

I think we should probably spell out Buffers but otherwise it sounds like no one objects to this.

[rsc]

Based on the discussion above, this proposal seems like a likely accept.
— rsc for the proposal review group