x/sys/unix: add IoctlSetIntPtr

[lhl2617]

What did you expect to see?

Original discussion: #46058

Some ioctl calls, such as https://www.kernel.org/doc/html/latest/watchdog/watchdog-api.html#setting-and-getting-the-timeout, modify the value in the ioctl call after the value is passed into the operation. Such ioctl calls are of the IOWR (IO write read) variant, as opposed to the IOR and IOW variants.

IoctlSetPointerInt is not able to return the modified value.

Proposed fix:

// IoctlSetModifiablePointerInt performs an ioctl operation which sets a
// pointer to an integer value on fd, using the specified request number.
//
// Use this if the ioctl operation may modify the value.
func IoctlSetModifiablePointerInt(fd int, req uint, value *int) error {
	return ioctl(fd, req, uintptr(unsafe.Pointer(value)))
}

[gopherbot]

Change https://golang.org/cl/318210 mentions this issue: x/sys/linux: add IoctlSetModifiablePointerInt that reflects changes in the ioctl value

[lhl2617]

Following the discussing in #46058, I further investigated: ioctl calls of the IOWR variant write the data to the kernel then read from it (see https://www.kernel.org/doc/html/latest/driver-api/ioctl.html). As of kernel v5.12 there are 200+ references to IOWR.

Previously I've been using https://github.com/vtolstov/go-ioctl which allows manual specification of ioctl calls, but having these automatically generated in x/sys would be neater and nicer.

[rsc]

We use "BytePtr" elsewhere, so we could call this IoctlSetIntPtr and just pretend IoctlSetPointerInt never happened.

[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

[lhl2617]

We use "BytePtr" elsewhere, so we could call this IoctlSetIntPtr and just pretend IoctlSetPointerInt never happened.

Updated CL to reflect this. (https://golang.org/cl/318210)

[rsc]

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

[rsc]

No change in consensus, so accepted. 🎉
This issue now tracks the work of implementing the proposal.
— rsc for the proposal review group

[lhl2617]

Implemented in CL 318210

[lhl2617]

#45585 mentions the importance of differentiating between (u)int(32|64). On a 64 bit system ints in the kernel are usually 32 bits, so this function may be flaky since Go's ints may be 64 bits.

Perhaps what is required is
IoctlSet(Ui|I)nt(32|64)Ptr
Just to be more explicit about the int width.

Putting the CL as WIP now.

Thoughts?