[eatonphil]

This is great! It would be even more useful to have this for Mac OSX too. A lot of the projects I do ends up being on both Mac and Linux. It's always a pain to find the corresponding number for the system call on Mac.

[legulere]

System calls have not stability guarantee on macOS. You should use libc instead. In general the use of syscalls directly is fairly limited.

Edit: for instance go broke once for macOS Sierra, when Apple changed the gettimeofday system call: https://github.com/golang/go/issues/16570

[int_19h]

Looking at this bug, it seems that Go has "fixed" it by fixing the syscall arguments, not by switching to libc.

Did they switch to libc since then?

If not, and given that Go apps are normally statically linked, does this mean that any precompiled Go app basically has a time bomb, in a sense that it'll break next time Apple changes some syscall?

[legulere]

The problem go has is that there’s a rather large overhead for calling C functions [1]. So they did not switch to calling libc as far as I know. And yes the next time Apple changes the syscalls, it will break again.

[1]: https://groups.google.com/forum/m/#!topic/golang-nuts/RTtMsg...

[int_19h]

Wow. So, basically, Go is a rather insular ecosystem - since you're paying the overhead of a context switch for every single FFI call - and if you use the stock APIs, it's essentially broken by design on macOS (since it uses APIs that Apple itself does not consider stable).

That's really sad. I was just beginning to like some aspects of it.

[zzzcpan]

Linux doesn't guarantee syscall stability either. Just make sure your wrappers can use a syscall table chosen at runtime, depending on which kernel you are running.

[wahern]

Yes it does, at least in the sense that syscalls which become officially public will never be removed from Linus' tree except in rare circumstances (i.e. proof that nobody is using it), nor will the arguments change. This is Linus' famous "never break user space" ABI mantra. While distributions may deprecate and remove them (e.g. sysctl(2)) they certainly won't be assigned new IDs. A table won't help in such cases.

[caf]

Exactly. This is why, for example, the original 'mmap' system call entry point on x86 still exists, even though it is overwhelmingly likely that every program on your machine is actually going to use the 'mmap2' entry point.

[RJIb8RBYxzAMX9u]

I think you're confusing driver APIs and syscalls. Both are infamous for their respective lack of, or guarantee of stability.

[smhenderson]

if you're going to implement that kind of overhead why not just use libc?

[zzzcpan]

I'm not sure what you mean by overhead. It's not that hard or expensive to choose a few function pointers on program start.

[zzzcpan]

There is a bsd/kern/syscalls.master file for every kernel at https://opensource.apple.com/source/xnu/