-
Notifications
You must be signed in to change notification settings - Fork 646
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
Avoid syscall.Syscall use on OpenBSD #404
Conversation
069ac48
to
90a1d44
Compare
Syscall numbers are not stable on OpenBSD, and hardcoding the msync syscall number will break bbolt on future versions of OpenBSD. Use the libc wrapper provided by golang.org/x/sys/unix instead. Signed-off-by: Josh Rickmar <[email protected]>
90a1d44
to
f5e8ebe
Compare
Thanks @jrick for the PR, which looks good to me. But have you tested it on OpenBSD? |
I have. It works the same as before (which is not perfect, there is a known bug in the kernel that the bbolt tests are exposing). |
Could you be more specific on this and paste the error the test exposed so that we can reference? |
See this thread: https://marc.info/?t=166694295600001&r=1&w=2 |
Thanks. |
To add to the sense of urgency, __syscall(2) is being removed now, and syscall(2) is planned to be removed shortly after 7.3 is released. |
@jrick could you please backport this PR to release-1.3? |
Done: #406 |
Syscall numbers are not stable on OpenBSD, and hardcoding the msync syscall number will break bbolt on future versions of OpenBSD. Use the libc wrapper provided by golang.org/x/sys/unix instead.
This fix can be confirmed by ktrace and kdump, which on OpenBSD -current, reports whether a syscall is made through syscall(2) or not. Before:
And after: