3 ms·

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

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 https://github.com/golang/go/issues/16570

zzzcpan 9y ago
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.
- smhenderson 9y ago
  if you're going to implement that kind of overhead why not just use libc?
  - zzzcpan 9y ago
    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.
- wahern 9y ago
  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 9y ago
    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 9y ago
  I think you're confusing driver APIs and syscalls. Both are infamous for their respective lack of, or guarantee of stability.
- dungle6 9y ago
  Your first sentence is absolutely false. The syscall table is the stable API of the linux kernel.
int_19h 9y ago
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 9y ago
  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/RTtMsgZi88Q https://groups.google.com/forum/m/#!topic/golang-nuts/RTtMsg...
  - int_19h 9y ago
    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 9y ago

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.

smhenderson 9y ago
if you're going to implement that kind of overhead why not just use libc?
- zzzcpan 9y ago
  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.
wahern 9y ago
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 9y ago
  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 9y ago
I think you're confusing driver APIs and syscalls. Both are infamous for their respective lack of, or guarantee of stability.
dungle6 9y ago
Your first sentence is absolutely false. The syscall table is the stable API of the linux kernel.

int_19h 9y ago

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 9y ago
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/RTtMsgZi88Q https://groups.google.com/forum/m/#!topic/golang-nuts/RTtMsg...
- int_19h 9y ago
  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.