-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
mountinfo: BSDs no longer need cgo nor reflect #114
Conversation
mountinfo/mountinfo_bsd.go
Outdated
count := int(C.getmntinfo(&rawEntries, C.MNT_WAIT)) | ||
if count == 0 { | ||
return nil, fmt.Errorf("failed to call getmntinfo") | ||
count, err := syscall.Getfsstat(nil, 1 /* MNT_WAIT */) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you define const MntWait = 1
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I defined MNT_WAIT.
mountinfo/mountinfo_bsd.go
Outdated
"reflect" | ||
"unsafe" | ||
) | ||
func getInfo(is []int8) string { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function name isn't descriptive.
func stringFromInt8Slice([]int8) string
might be better.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I renamed it to int8SliceToString.
Please squash commits |
Looks like one function is not defined in at least one of the variants
|
This function is defined in mountinfo/mountinfo_freebsd.go for FreeBSD and Darwin. And it has passed golangci-lint on FreeBSD. I think this is a problem with GitHub Actions, but I don't have a MAC, maybe you can have a try. |
I reproduced it, and I will fix it. |
I renamed mountinfo_freebsd.go to mountinfo_freebsdlike.go, and it got fixed. |
Signed-off-by: 谢致邦 (XIE Zhibang) <Yeking@Red54.com>
mountinfo.Mountpoint = int8SliceToString(entry.F_mntonname[:]) | ||
mountinfo.FSType = int8SliceToString(entry.F_fstypename[:]) | ||
mountinfo.Source = int8SliceToString(entry.F_mntfromname[:]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess you forgot to switch to unix.ByteSliceToString
here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, this is correct.
In syscall
, freebsd, darwin, and openbsd are all int8 arrays.
https://cs.opensource.google/go/go/+/refs/tags/go1.18.1:src/syscall/ztypes_freebsd_amd64.go;l=145
https://cs.opensource.google/go/go/+/refs/tags/go1.18.1:src/syscall/ztypes_darwin_amd64.go;l=100
https://cs.opensource.google/go/go/+/refs/tags/go1.18.1:src/syscall/ztypes_openbsd_amd64.go;l=117
But in golang.org/x/sys/unix
, freebsd and darwin are byte arrays, only openbsd is int8 array.
https://cs.opensource.google/go/x/sys/+/33da011f:unix/ztypes_freebsd_amd64.go;l=129
https://cs.opensource.google/go/x/sys/+/33da011f:unix/ztypes_darwin_amd64.go;l=100
https://cs.opensource.google/go/x/sys/+/33da011f:unix/ztypes_openbsd_amd64.go;l=99
This is why I chose syscall
before.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, weird.
This is probably something that needs to be fixed in x/sys/unix. Something similar to e.g. https://go-review.googlesource.com/c/sys/+/359674 needs to be done.
If you have openbsd running, you can prepare a patch to x/sys/unix similar to the above; if not, I can try to do that or we can maybe kindly ask @tklauser
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I will make a patch to x/sys/unix for OpenBSD.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kolyshkin @thaJeztah Can we merge this? 🙏 |
I see the intent was to upstream changes to golang.org/x/sys; https://github.com/moby/sys/pull/114/files#r855976616, but looking at that pull request, it looks like there's things to address. Not sure if that's a blocker for this change (although if golang.org/x/sys will change things and it breaks this code, I guess that's not desirable) @kolyshkin as you were looking at that part; perhaps you have ideas? |
So, https://go-review.googlesource.com/c/sys/+/401734 has a comment that needs addressing. I think @Red54 should look into it. Nevertheless, it's not clear if the change will be accepted, so let's merge this for now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@kolyshkin Can we have a new release? 🙏 |
var bs []byte | ||
for _, i := range is { | ||
if i == 0 { | ||
break | ||
} | ||
bs = append(bs, byte(i)) | ||
} | ||
return string(bs) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry I overlooked it. This function is probably doing some excessive allocations and copying and should be rewritten
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can not think of a better way without unsafe
. If you are sure, then I will rewrite it with unsafe
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rewrited with unsafe
.
#117
@kolyshkin re: moby/sys release required for FreeBSD support in nerdctl. Is there any way to fast track the release? I see it's just the OpenBSD code that is preventing us from moving forward. If that's the case, maybe we could use the older (cgo) implementation for OpenBSD? Would that be viable? cc @Red54 & @AkihiroSuda |
What is needed to be done is:
@Red54 @akhramov feel free to work on this. Once done and merged, we can cut a release. |
@kolyshkin thanks! So, something like #118? |
Alternative PR for #113