Make types for OpenBSD/arm64 #993
Conversation
|
Thanks a lot @vext01! I should buy a Raspberry 4 one day :) You can test your changes with |
|
OK, I've added a commit for the v3 types, but it doesn't appear to build. In fact, I'm unsure if I'm doing this right. The struggles of someone who's never used golang 🆘 So I guess we need to use But it seems to be enough to run the build now: |
|
There's a type mismatch in the code generated by mktypes.sh, it doesn't build currently. I don't understand why yet, it looks like it's the |
|
It rings a bell that the signedness of a char varies between platforms. |
|
Yes, here:
I don't know if the same semantics are expected of go? |
|
We generate some types from their C definition, so we inherit hat indeed, thanks for the pointer. We could just blindly cast the slices to uint8 like in the following diff diff --git a/disk/disk_openbsd.go b/disk/disk_openbsd.go
index e675580..f71862f 100644
--- a/disk/disk_openbsd.go
+++ b/disk/disk_openbsd.go
@@ -87,7 +87,11 @@ func IOCountersWithContext(ctx context.Context, names ...string) (map[string]IOC
if err != nil {
continue
}
- name := common.IntToString(d.Name[:])
+ uint8Name := make([]uint8, len(d.Name))
+ for i, v := range d.Name {
+ uint8Name[i] = uint8(v)
+ }
+ name := common.UintToString(uint8Name)
if len(names) > 0 && !common.StringsHas(names, name) {
continue
diff --git a/process/process_openbsd.go b/process/process_openbsd.go
index 0404b4b..c439d92 100644
--- a/process/process_openbsd.go
+++ b/process/process_openbsd.go
@@ -46,7 +46,11 @@ func (p *Process) NameWithContext(ctx context.Context) (string, error) {
if err != nil {
return "", err
}
- name := common.IntToString(k.Comm[:])
+ uint8Name := make([]uint8, len(k.Comm))
+ for i, v := range d.Name {
+ uint8Name[i] = uint8(v)
+ }
+ name := common.UintToString(uint8Name)
if len(name) >= 15 {
cmdlineSlice, err := p.CmdlineSliceWithContext(ctx)
diff --git a/v3/disk/disk_openbsd.go b/v3/disk/disk_openbsd.go
index 24324a4..7530901 100644
--- a/v3/disk/disk_openbsd.go
+++ b/v3/disk/disk_openbsd.go
@@ -87,7 +87,11 @@ func IOCountersWithContext(ctx context.Context, names ...string) (map[string]IOC
if err != nil {
continue
}
- name := common.IntToString(d.Name[:])
+ uint8Name := make([]uint8, len(d.Name))
+ for i, v := range d.Name {
+ uint8Name[i] = uint8(v)
+ }
+ name := common.UintToString(uint8Name)
if len(names) > 0 && !common.StringsHas(names, name) {
continue
diff --git a/v3/process/process_openbsd.go b/v3/process/process_openbsd.go
index 7325f09..1b29204 100644
--- a/v3/process/process_openbsd.go
+++ b/v3/process/process_openbsd.go
@@ -46,7 +46,11 @@ func (p *Process) NameWithContext(ctx context.Context) (string, error) {
if err != nil {
return "", err
}
- name := common.IntToString(k.Comm[:])
+ uint8Name := make([]uint8, len(k.Comm))
+ for i, v := range d.Name {
+ uint8Name[i] = uint8(v)
+ }
+ name := common.UintToString(uint8Name)
if len(name) >= 15 {
cmdlineSlice, err := p.CmdlineSliceWithContext(ctx)At least it compiles from what I see now. Would test with these changes applied with the same commands as in #993 (comment) on your arm64 host on openbsd? |
|
I guess you also need the following diff for the tests to run but it's unrelated to your PR itself diff --git a/v3/process/process_openbsd.go b/v3/process/process_openbsd.go
index 6e45d84..7325f09 100644
--- a/v3/process/process_openbsd.go
+++ b/v3/process/process_openbsd.go
@@ -241,7 +241,7 @@ func (p *Process) MemoryInfoWithContext(ctx context.Context) (*MemoryInfoStat, e
if err != nil {
return nil, err
}
- pageSize, err := mem.GetpageSizeWithContext(ctx)
+ pageSize, err := mem.GetPageSizeWithContext(ctx)
if err != nil {
return nil, err
} |
|
Hi @Lomanic It seems the patch doesn't apply: |
|
This patch applies with The second patch is not needed anymore if you rebase from master ( |
|
Hi @vext01, will you be able to test the changes in #993 (comment) ( |
|
Before and after a rebase, I get: Can you make a branch containing the changes you'd like tested and I'll try that? |
These were generated on OpenBSD-current on a Raspberry Pi 4.
…ifferent x86/arm (un)signed char types Ref shirou#993 (comment)
|
There you go https://github.com/Lomanic/gopsutil/tree/openbsd-arm64 (with your commits squashed and rebased from upstream master). (It could have even been simpler to enable "repository maintainer permissions on existing pull requests", never used this function yet) |
|
Thanks. I cloned your repo to And it exits I also tried just |
You should have cloned it to |
|
Oops. My apologies. I really know nothing about golang. So, I think this is right: Here's the output of the test (I had to Looks like we are getting somewhere. |
|
Done! Sorry for the delay! |
|
Let's not forget this one. |
…ifferent x86/arm (un)signed char types Ref shirou#993 (comment)
…ifferent x86/arm (un)signed char types Ref shirou#993 (comment)
|
Hi, thanks for the reminder, I overlooked it in my last message in fact, as I didn't see the following error I did a silly copy-paste mistake it seems (from the disk package I can see now), I updated my branch at https://github.com/Lomanic/gopsutil/tree/openbsd-arm64 (I'm not sure I can push to your branch) and I could test it on my old OpenBSD 6.5 i386 VM this time, without issues ; the process package now builds and has its tests run successfully. If you can confirm me that tests run successfully on your arm64 host also (minus the TestCpu_times failing test, it's unrelated), it looks like we will finally be able to merge this. Thanks for staying for so long over here, appreciated. |
|
Hello, I'm running OpenBSD -current on my Raspberry Pi 4 (2GB RAM version). I've run |
…ifferent x86/arm (un)signed char types Ref shirou#993 (comment)
Related to #5121 Note: OpenBSD is stub yet. This will be fixed after upstream PR gets resolved shirou/gopsutil#993
|
superseded by #1052 |
Related to rclone#5121 Note: OpenBSD is stub yet. This will be fixed after upstream PR gets resolved shirou/gopsutil#993
As requested here.
These were generated on OpenBSD-current on a Raspberry Pi 4.
Can you tell me how to test the build and run the test suite? I don't know anything about golang!
Fixes #992