Several xnu syscalls are actually paired with a userspace wrapper function that does some extra stuff. Existing syscalls may even become wrapped in a subsequent release if needed.
I believe this article[1] definitively answers this as being the case.
> Whereas Linux keeps a hard compatibility guarantee.
Not being a troll here... Why would anyone care unless they are writing a libc replacement? Before anyone objects regarding compatibility with programs written for older versions of OS-X, there have been compatibility libraries distributed for every version I can recall. To wit, I run the Pages app from iWork '09 regularly.
1 - https://developer.apple.com/library/mac/qa/qa1118/_index.htm...
Statically compiling the libc is common with proprietary Linux software, if I remember correctly.
Thanks for clarifying this point for me.
- So that you can feel safe upgrading your kernel without upgrading your whole userspace. (Linus harps on this one a lot.)
- So that there can be multiple competing libc's. Linux is used in a lot of diverse environments, and the tradeoffs made by glibc (in terms of bloat, license, etc.) are not necessarily the best for everyone. Android does not use glibc, for example.
- So that you can isolate apps from each other using containers (hermetic chroot environments), where different containers may have entirely different libc. Docker (and my own Sandstorm.io) relies very heavily on Linux's syscall ABI compatibility promises.
- Because the syscall ABI is frankly a much clearer boundary than the libc ABI, and arguably easier to keep backwards-compatible. An app literally _can't_ break this boundary and access the private interfaces beneath (assuming a secure implementation, lol).
Linux doesn't have any single fixed libc, the system call interface is the public API. Indeed there are many different libc's used in different linux applications - glibc on many desktop distros, bionic libc on android, uclibc, musl and others on various embedded/specialized setups.