Add netbsd's syscall.h.

[m-ou-se]

This adds https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/sys/syscall.h

(I only need SYS___futex, but I added the rest as well.)

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @Amanieu (or someone else) soon.

Please see the contribution instructions for more information.

[m-ou-se]

I don't know if these are stable, or how to find out if we can rely on these constants.

[thomcc]

I think asking on one of the NetBSD mailing lists might¹ be appropriate. Perhaps tech-userlevel? (I'm not familiar, this may be the wrong place).

Footnotes

1. Just because common wisdom is that BSDs don't have a stable syscall ABI. ↩

[semarie]

from cvs syscall.h history, the values seems relatively stable (in sense they doesn't change). but beware that it isn't the same stability than Linux: values could be removed if the syscall gone.

if you need some of them (because no libc wrapper), just adding the minimum required constants should be safe. else, you could lead to problems regarding the stability provided by rust libc crate (no symbols removed) versus the stability provided by the target (where symbols could be removed between major OS version).

[thomcc]

Hm, I wonder if it's better to just put it inside the stdlib, where it's not exposed publicly and would just be used for the internal implementation... we'd have to fix it if it were removed, but it wouldn't break anybody downstream.

(Well... sort of. I guess it would mean if it were removed, code using older libstd would stop working, hm...)

[m-ou-se]

Hm, I wonder if it's better to just put it inside the stdlib

Yeah maybe. In that case we should only merge #2762 and keep SYS___futex inside std.

[Amanieu]

Boost seems to use the syscall (and syscall.h) directly, so it's fine to add these definitions to libc.

@bors r+

[bors]

📌 Commit f08e26c has been approved by Amanieu

[bors]

⌛ Testing commit f08e26c with merge 3404b50...

[semarie]

@Amanieu but does Boost why refuse to remove them if NetBSD do a breaking change ?

[Amanieu]

The syscalls are part of the public headers so I guess you would just be expected to rebuild boost with the updated headers.

[thomcc]

Boost also uses __ulock functions for macOS, even though they are unstable (and will get you rejected from app stores: boostorg/atomic#55 for that reason).

So I don't know if boost using something is indicative of its stability. Or at least, it is not indicative that we can use them.

[bors]

💔 Test failed - checks-actions

[semarie]

@Amanieu for me, the problem is if all of these defines are commited in rust libc, it means that problems will arrived when NetBSD will remove one of them: rust libc stability will not permit to remove them.

Please note that importing only SYS_futex (or what it is effectivily required for rust-lang/rust/issues/93740) would be fine. as it is limiting the possible problems.

[Amanieu]

In that case I'll just close this for now, we can just hard-code the sycall number in the standard library.