NetBSD has both struct uvmexp (used internally) and struct uvmexp_sysctl
(preferred for interfacing from user code). Expose the latter as type
Uvmexp with the same interface as on OpenBSD.
I am not sure if it makes sense to even have a name parameter for
SysctlUvmexp, since the only valid value can be "vm.uvmext2".
Change-Id: I40a743536c28e3fb7a54253768db35b1629fabfe
Reviewed-on: https://go-review.googlesource.com/c/sys/+/460156
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Benny Siegert <bsiegert@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
The current code has continued to work on OpenBSD, since it has been using
syscall(2) via libc. However, the system call numbers are still hardcoded in
golang.org/x/sys/unix. Various system call changes have been made in OpenBSD,
resulting in changes to the system call numbers and arguments, which now
fail when this package is used.
Switch to calling various system calls directly via libc, rather than calling
via libc using syscall(2).
Unfortunately, this will no longer work on upstream Go since the changes
needed to convert it to libc are still blocked pending review. This means
that we're in a less than ideal situation where upstream Go openbsd/mips64
does not work on any supported OpenBSD release (in fact has not since
OpenBSD 6.8, which was EOL over a year ago), however golang.org/x/sys/unix
is now unusable with the Go package that ships with supported releases via
OpenBSD ports. It would seem that being able to actually use Go software on
a supported OpenBSD release trumps maintaining compatibility with the
unusable upstream Go source.
Updates golang/go#36435
Change-Id: Id8947cd0e4e05709e96c3d4478ac8789b924d416
Reviewed-on: https://go-review.googlesource.com/c/sys/+/459497
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
This clarifies these functions' behavior when the non-control data is
empty but there is a control data present.
It also makes clear the difference between Sendmsg, SendmsgN, and
SendmsgBuffers, and between Recvmsg and RecvmsgBuffers.
Fixesgolang/go#56911
Change-Id: I1e35659e66e493c192af7f5a426a316f6052475c
Reviewed-on: https://go-review.googlesource.com/c/sys/+/456816
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Add a syscall wrapper for SYS_RT_SIGPROCMASK and export it as
PthreadSigmask. The latter is defined by POSIX and can therefore
be implemented by Darwin, etc. later on.
Follow the approach used by Signalfd of passing _C__NSIG/8 as
sigsetsize. This avoids exporting _C__NSIG and allows the syscall
to work with the current definition of Sigset_t, which doesn't
match the kernel definition of Sigset_t.
Updates golang/go#55349
Change-Id: I49dc93366a7d316d820b0c25ecdef2ebb584634b
Reviewed-on: https://go-review.googlesource.com/c/sys/+/435095
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
On windows, use unsafe.Slice instead of unsafeheader as already the case
for unix and plan9.
The pointers are already *byte/*uint16, so the type conversion can be
omitted as well.
Change-Id: Ida7264cc0c1948bf563ed91d51e637edcdafb77a
Reviewed-on: https://go-review.googlesource.com/c/sys/+/430515
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Bryan Mills <bcmills@google.com>
This was originally copied over from package syscall where it was
replaced by internal/itoa in CL 301549.
For golang.org/x/sys/unix we may import strconv, so use strconv.Itoa
instead.
Change-Id: Iac125fbd0f64c385f9f0c02d4a7af762364b67aa
Reviewed-on: https://go-review.googlesource.com/c/sys/+/425304
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Heschi Kreinick <heschi@google.com>
The existing value for M1 is 64, which is the same as other arm64 cpus.
But the correct cacheLineSize for M1 should be 128, which can be
verified using the following command:
$ sysctl -a hw | grep cachelinesize
hw.cachelinesize: 128
Fixesgolang/go#53075
Change-Id: I555716ed412cdc02941c8b1d9767952f7ad6678c
Reviewed-on: https://go-review.googlesource.com/c/sys/+/408614
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Joedian Reid <joedian@golang.org>
Reviewed-by: Keith Randall <khr@google.com>
The current code has continued to work on OpenBSD, since it has been using
syscall(2) via libc. However, the system call numbers are still hardcoded in
golang.org/x/sys/unix. Various system call changes have been made in OpenBSD,
resulting in changes to the system call numbers and arguments, which now
fail when this package is used.
Switch to calling various system calls directly via libc, rather than calling
via libc using syscall(2).
Updates golang/go#36435
Change-Id: If8e403f0fda7a8b68da71c1f4efba7785b14edf5
Reviewed-on: https://go-review.googlesource.com/c/sys/+/421800
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
The current code has continued to work on OpenBSD, since it has been using
syscall(2) via libc. However, the system call numbers are still hardcoded in
golang.org/sys/unix. Various system call changes have been made in OpenBSD,
resulting in changes to the system call numbers and arguments, which now
fail when this package is used.
Switch to calling various system calls directly via libc, rather than calling
via libc using syscall(2).
Updates golang/go#36435
Change-Id: Ib42d5415ef35c7f7b9cbc55adaf7ca15973ab287
Reviewed-on: https://go-review.googlesource.com/c/sys/+/421798
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
The current code has continued to work on OpenBSD, since it has been using
syscall(2) via libc. However, the system call numbers are still hardcoded in
golang.org/sys/unix. Various system call changes have been made in OpenBSD,
resulting in changes to the system call numbers and arguments, which now
fail when this package is used.
Switch to calling various system calls directly via libc, rather than calling
via libc using syscall(2).
Updates golang/go#36435
Change-Id: Iadd5734fd4a2421d758883293bd8a6759fc52ca7
Reviewed-on: https://go-review.googlesource.com/c/sys/+/421797
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Than McIntosh <thanm@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
The current code has continued to work on OpenBSD, since it has been using
syscall(2) via libc. However, the system call numbers are still hardcoded in
golang.org/sys/unix. Various system call changes have been made in OpenBSD,
resulting in changes to the system call numbers and arguments, which now
fail when this package is used.
Switch to calling various system calls directly via libc, rather than calling
via libc using syscall(2).
Updates golang/go#36435
Change-Id: I836a484b14e0a427ac565315e27f0de1e9a5d021
Reviewed-on: https://go-review.googlesource.com/c/sys/+/421796
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
