-
Notifications
You must be signed in to change notification settings - Fork 17.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: x/sys/unix: add IoctlRetInt() #33966
Comments
I'm OK with adding such a function for Linux. |
OK with me. |
Change https://golang.org/cl/192780 mentions this issue: |
@tklauser I was able to find at least one Solaris ioctl that also uses syscall return value, it is |
... so I have added this new function this for all UNIX versions |
I propose to add the following function to x/sys/unix:
and amend the
IoctlGetInt()
documentation with the following text:Motivation
Currently,
x/sys/unix
provides a few functions to deal with ioctls. In particular, IoctlGetInt(), which "performs an ioctl operation which gets an integer value". It does that by passing a pointer to an integer to a syscall and returning that integer. The value returned from syscall is treated as success/failure flag (0 means success, -1 means failure, and in such caseerrno
is used to figure out the underlying error).It appears that there are a few ioctls in Linux (I'm not sure about other OSs) that does not use the above way to return an int, but rather they use the syscall's return value (in case it's not negative). As ioctl(2) man page says,
Currently I am aware of at least 6 ioctls that do that (return the value directly):
LOOP_CTL_*
ioctls on/dev/loop-control
(all 3 of them). Source: loop(4)NS_*
ioctls (3 out of 4) on/proc/PID/ns/*
. Source: ioctl_ns(2)There might be some more, but since in general ioctls are not well documented and there's no definitive list. I am not sure how many more are there.
Obviously, using
IoctlGetInt()
for such ioctls would be a big mistake, as 0 will always be returned. For example, here is the bug in Docker: moby/moby#39801The text was updated successfully, but these errors were encountered: