The code generator produces -0x1 for (~0) from the tipc.h C header, but this
value is unusable in Go as a uint32. Undefine and replace this value with
the appropriate constant for TIPC_WAIT_FOREVER.
Fixesgolang/go#34310
Change-Id: Ic6ab0ddd14394e15868085e2123a9a97a841bc6d
Reviewed-on: https://go-review.googlesource.com/c/sys/+/195757
Run-TryBot: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Adds initial constants and types to use with SockaddrTIPC. For more
information on TIPC, see: http://tipc.sourceforge.net/.
Because the C struct sockaddr_tipc makes use of a union for its addr
field, I have created a wrapping layer in SockaddrTIPC that uses
an interface to determine which variant is in use.
Tests accompany this change due to the complexity of this code. There
is currently little test coverage in the Sockaddr-related code, but
perhaps this is something that could be picked up as a relatively
straightforward task for a new contributor.
Change-Id: I5033a0685cb7128d4b1a23d18aca71c202d0c0aa
Reviewed-on: https://go-review.googlesource.com/c/sys/+/187960
Run-TryBot: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Add IoctlRetInt() for ioctls that use syscall's return value
as an output parameter. Add a unit test for Linux, and the
NS_GET_ defines that it requires (see ioctl_ns(2)).
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 case errno
is used to figure out the underlying error).
It appears that there are a few ioctls in Linux and at least one
in Solaris, which do not use the above way to return an int, instead
they use the syscall's return value (in case it's not negative).
As Linux ioctl(2) man page says,
> RETURN VALUE
> Usually, on success zero is returned. A few ioctl() requests
> use the return value as an output parameter and return
> a nonnegative value on success. On error, -1 is returned,
> and errno is set appropriately.
Currently I am aware of at least 6 Linux 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)
And one in Solaris:
* I_FIND ioctl, source: streamio(7i).
There might be some more ioctls like the ones above, but since
ioctls are scarcely documented, it is hard to say how many more.
Obviously, using IoctlGetInt() for such ioctls would be a big
mistake, as 0 will always be returned. For example, there was
a bug in Docker's pkg/loopback (moby/moby#39801).
[v6: make it linux-specific for now]
Fixesgolang/go#33966
Change-Id: Ie64f72fd84101b955ba14519a357e06a66d685d0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/192780
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
This teaches unix/mksyscall.go about mapping uint64 to syscall
arguments, similar to existing handling of int64.
Change-Id: I536b4b09bbf6a8e3016565a4a04d2b9d32cbc624
Reviewed-on: https://go-review.googlesource.com/c/164664
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Drop the manually defined *_XDP constants which were added to glibc.
Install python3 instead of python because glibc's confugure script now
requires at least 3.4.
Change-Id: Ic19ff4d8aa4dbadeb5438e331ccafeafc2cc9925
Reviewed-on: https://go-review.googlesource.com/c/160957
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
This CL introduces the Getrandom syscall. Allowing users of
sufficiently new kernels (3.17) to detect when the operating system
lacks enough entropy to generate cryptographic random data. See:
http://man7.org/linux/man-pages/man2/getrandom.2.html
As we have updated the syscall numbers, the Getrandom function can
just be generated normally. The only other change is to mkerrors.sh
to include the GRND_* flags for getrandom from <linux/random.h>.
It is important to note that currently the mkerrors.sh script cannot
actually be run as it has fallen behind the 4.10 kernel. The GRND_*
flags were added manually.
This was originally part of a larger commit that was split up.
See CL: https://go-review.googlesource.com/37570
Change-Id: I464088a9c9f7224abdcdae476b30a4f2f412d9f5
Reviewed-on: https://go-review.googlesource.com/37589
Reviewed-by: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
