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>
OpenBSD 7.1 onwards expose the aarch64 ISAR0 and ISAR1 registers via sysctl:
$ sysctl machdep
machdep.compatible=apple,j274
machdep.id_aa64isar0=153421459058925856
machdep.id_aa64isar1=1172796674562
Implement CPU feature detection for openbsd/arm64 based on this information.
Updates golang/go#31746
Change-Id: I6dc473d93ccff720582c05b75456de51269bc3e5
Reviewed-on: https://go-review.googlesource.com/c/sys/+/421799
Run-TryBot: Joel Sing <joel@sing.id.au>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Reviewed-by: Than McIntosh <thanm@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Rather than reading in multiple files and concatenating into a string,
pass the list of file names to the function, which in turn can read and
process the list before generating output.
Use sort.Strings rather than handrolling a sort function. Nest errors
where applicable and add usage when run without sufficient arguments
(rather than panicing).
Change-Id: I179fd5a3b98ddbdb7b39fe7df87bc767a82598fa
Reviewed-on: https://go-review.googlesource.com/c/sys/+/421794
Reviewed-by: Than McIntosh <thanm@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Run-TryBot: Joel Sing <joel@sing.id.au>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Tobias Klauser <tobias.klauser@gmail.com>
Don't shadow the empty var when determining whether to send a single
byte when iovecs are empty but oob is non-empty. This will lead to the
n value correctly being reset to 0 before return.
No test because it's not possible to trigger this case on all platforms,
e.g. darwin where sendmsg with empty buf and non-empty oob returns
EINVAL.
This was introduced by CL 412497 and CL 419396.
Updates golang/go#52885
Change-Id: Iafc5a4b22e10b396ba5f7d4f2ac1c50df195a125
Reviewed-on: https://go-review.googlesource.com/c/sys/+/419914
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Reviewed-by: Florian Lehner <lehner.florian86@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
CL 399336 added support for generating linux/loong64 types and constants
and CL 406794 switched it to use gotip after support for linux/loong64
was merged. The upcoming Go 1.19 release will support that platform, so
switch to use 1.19rc2.
Change-Id: Id3be69eb8f04bdf215f248df09bb5da9456494e7
Reviewed-on: https://go-review.googlesource.com/c/sys/+/419395
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
In 2009, Google's open-source lawyers asked us to create the AUTHORS
file to define "The Go Authors", and the CONTRIBUTORS file was in
keeping with open source best practices of the time.
Re-reviewing our repos now in 2022, the open-source lawyers are
comfortable with source control history taking the place of the
AUTHORS file, and most open source projects no longer maintain
CONTRIBUTORS files.
To ease maintenance, remove AUTHORS and CONTRIBUTORS from all repos.
For golang/go#53961.
Change-Id: Idc0002448db29c764256656d9ae3948ad7f1e6a0
Reviewed-on: https://go-review.googlesource.com/c/sys/+/418903
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Russ Cox <rsc@golang.org>
Reviewed-by: David Chase <drchase@google.com>
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>
CL 399336 added support for generating linux/loong64 types and constants
by using a patched version of Go 1.18. The necessary changes have since
been submitted to gotip, so use Go build from the master branch to
generate types and consts.
The changes in the cgo -godefs generated comments are due to CL 396936,
also see go.dev/issue/52063
Change-Id: I314156675e79ba77b9eb1fa1845b20ca974ec77a
Reviewed-on: https://go-review.googlesource.com/c/sys/+/406794
Reviewed-by: Ian Lance Taylor <iant@google.com>
Reviewed-by: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com>
Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com>
Go releases before Go 1.17 are no longer supported, and Go 1.17
supports the newer "//go:build" syntax, so the older "//+build"
variation is no longer required by Go's support policy. However, the
x/sys module is very low-level and empirically some users are still on
unsupported Go releases, so there is little harm in adding the older
variations.
Fixesgolang/go#52668.
Change-Id: Ieb8e64e450b9d795f2753fc5f99b36816a3dbff3
Reviewed-on: https://go-review.googlesource.com/c/sys/+/403695
Run-TryBot: Bryan Mills <bcmills@google.com>
Reviewed-by: Russ Cox <rsc@golang.org>
The Faccessat call checks the user, group, or other permission bits of a
file to see if the calling process can access it. The test to see if the
group permissions should be used was made with the wrong group id, using
the process's group id rather than the file's group id. Fix this to use
the correct group id.
This change only affects Linux versions prior to 5.8. Linux 5.8 added
the faccessat2 system call, which we use in preference to the internal
implementation.
No test since we cannot easily change file permissions when not running
as root and the test is meaningless if running as root.
For golang/go#52313
Change-Id: I6fa64379a50c9380207eab9d095ef7fbd05a2d59
Reviewed-on: https://go-review.googlesource.com/c/sys/+/400074
Run-TryBot: Damien Neil <dneil@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
