tklauser / go-sysconf

sysconf for Go, without using cgo
https://pkg.go.dev/github.com/tklauser/go-sysconf
BSD 3-Clause "New" or "Revised" License
141 stars 27 forks source link

generate zsysconf_values_linux_loongarch64.go #17

Closed zunley closed 2 years ago

zunley commented 3 years ago

I run go build . && ./mksysconf generate zsysconf_values for linux_loongarch64.

Currently golang of loongarch64 is waiting for the community to receive. All these values meets the definition in golang.org/x/sys/unix.

I open this PR because gopsutil needs. I don’t know if this approach is reasonable, please contact me if you have other suggestions.

root@merore-larch:/wk/github.com/merore/go-sysconf# file mksysconf
mksysconf: ELF 64-bit LSB executable, LoongArch-64, version 1 (SYSV), statically linked, Go BuildID=1zmjGuE9DKs8ISR2WaPz/eB5xeSi_POWE-l46-xb_/ZV6DwaJrPNtbVLEIOfCU/4b2Pcx90zjX8qISsaqb4, not stripped

root@merore-larch:/wk/github.com/merore/go-sysconf# lscpu 
Architecture:        loongarch64
Byte Order:          Little Endian
CPU(s):              4
On-line CPU(s) list: 0-3
Thread(s) per core:  1
Core(s) per socket:  4
Socket(s):           1
NUMA node(s):        1
Model name:          Loongson-3A5000LL
CPU max MHz:         2300.0000
CPU min MHz:         225.0000
BogoMIPS:            4592.64
L1d cache:           64K
L1i cache:           64K
L2 cache:            256K
L3 cache:            16384K
NUMA node0 CPU(s):   0-3
tklauser commented 3 years ago

It looks like the decision is GOARCH=loong64, see https://github.com/golang/go/issues/46229#issuecomment-861154674 The GOARCH value was added to golang/go in https://github.com/golang/go/commit/2b00a54baf2b677b2aaddd93c25b11ea4642a86f already.

@merore could you please update the PR to use GOARCH=loong64 and also add the corresponding build tags for backwards compatibility? Then we should be good to merge. Thanks!

xen0n commented 3 years ago

Currently the kernel and libc ABIs are not upstream yet, thus subject to possible changes. The early version I saw was heavily MIPS-based, so has very little chance to be merged as-is; and this PR contains values from that era, I think. So maybe this PR should wait until the ABIs are sufficiently settled?

tklauser commented 3 years ago

Thanks for the context @xen0n! I agree, in that case let's wait until the ABIs in kernel and libc are stable.