This changes some fields of openbsd Statfs_t from arrays of int8
to arrays of byte. This makes the types of those fields correspond to
the types used on most other BSD systems (Darwin, FreeBSD, NetBSD),
and simplifies the conversion to Go string.
Similar changes: CL 359674, CL 259903, CL 74331.
Note that while this patches mkpost.go, the end result is obtained by
manual editing of ztypes_openbsd_*.go files. The reasons for this are:
1. automatic regeneration (tried on openbsd 6.9 / amd64) brings in way
too many changes (5 files changed, 193 insertions, 45 deletions).
2. I could not figure out how to run openbsd on non-amd64.
Nevertheless, this change is sufficient, meaning if someone will
actually end up regenerating these (see e.g. CL 347649) after this
commit is merged, the fields will still be kept as arrays of byte.
Change-Id: I4520889f11f6ac2d9befe17c7a77186198c08cd2
Reviewed-on: https://go-review.googlesource.com/c/sys/+/407195
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: 谢致邦 <xiezhibang@gmail.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
CL 340370 introduced (*Ifreq).Name method which scans the Ifrn field
for \0 twice -- first explicitly, when by calling BytePtrToString.
It seems more straightforward to use ByteSliceToString instead. The
differences are:
- simpler code;
- no double scanning for \0;
- in case there is no \0 in the Ifrn (unlikely), the full string
(rather than an empty string) is now returned.
With the last item in mind, the test case with no \0 as input that
expects empty output fails, so drop it. Alternatively, we could test
that it returns the full string, but it will be essentially testing
ByteSliceToString, which is not the point.
Cc: Matt Layher <mdlayher@gmail.com>
Change-Id: I31d4f6dbe98aae5120f9b2246c93ceaa6a165395
Reviewed-on: https://go-review.googlesource.com/c/sys/+/407194
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Matt Layher <mdlayher@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Matt Layher <mdlayher@gmail.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
The close_range(2) syscall is available since Linux kernel v5.9,
with additional functionality of CLOSE_RANGE_CLOEXEC since v5.11.
No tests are required since this is a bare syscall.
Change-Id: I410470e3713e2005cc7acf24d1347938fe05ef63
Reviewed-on: https://go-review.googlesource.com/c/sys/+/301409
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Trust: Emmanuel Odeke <emmanuel@orijtech.com>
openat2 is a new syscall added to Linux 5.6. It provides a superset of
openat(2) functionality, extending it with flags telling the kernel how
to resolve the paths.
For more info, see https://lwn.net/Articles/803237/
NOTE that this is a second attempt to add the call; the previous one
(https://golang.org/cl/227280) was reverted
(https://golang.org/cl/227846) due to the test case failure on ARM
(https://golang.org/issue/38357).
This CL has the test case reworked to be less assumptive to the testing
environment. In particular, it first tries if the most simplistic
openat2() call succeeds, and skips the test otherwise. It is done that
way because CI can be under under different kernels and in various
envrionments -- in particular, Docker+seccomp can result in EPERM from a
system call (which is not expected otherwise).
For previous discussions about the test case, see
https://golang.org/cl/227865.
Change-Id: I4276cf13dc29ecbdbdc9c58da0f76270f585a67f
Reviewed-on: https://go-review.googlesource.com/c/sys/+/253057
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
openat2 is a new syscall added to Linux 5.6. It provides a superset
of openat(2) functionality, providing a way to extend it in the future,
and (for now) adding flags telling the kernel how to resolve the path.
For more info on openat2, see https://lwn.net/Articles/803237/
A primitive test case is added to check that Openat2 works as
it should. Tested to skip on kernel 5.5 and pass on 5.6.
Change-Id: Ib8bbd71791762f043200543cecdea16d2fd3c81d
Signed-off-by: Kir Kolyshkin <kolyshkin@gmail.com>
Reviewed-on: https://go-review.googlesource.com/c/sys/+/227280
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
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>
Kir Kolyshkin