
OS X BSD System Calls Reference - adamnemecek
http://dyjakan.sigsegv.pl/osx-bsd-syscalls/
======
davvid
Seeing all of the syscalls in one place really puts things in perspective. The
#ifdef markers are a nice touch, too.

This makes me wonder, what would this look like for plan9? Just FS-related
syscalls, and that's it? Curious...

~~~
vezzy-fnord
_This makes me wonder, what would this look like for plan9?_

[http://aiju.de/misc/plan9-syscalls](http://aiju.de/misc/plan9-syscalls)

~~~
carterschonwald
i like how the plan9 system calls list can fit on an index card.

I guess that i'm then wondering, to what extent are the profusion of api calls
on bsd/linux (by comparison) due to which of the following: a) legacy of
evolving richer apis while supporting older ones b) poorer factoring of
abstractions c) different special casing for various performance or security
related primitives?

------
ori_b
Note that the BSD system calls do not cover the full functionality of OSX, and
the mach interfaces are necessary. For example, sleep() needs to use the Mach
message interfaces.

~~~
contingencies
Embrace and extend? How is this different to Android vs. the Linux kernel?

~~~
beltex
_" The kernel of NeXTSTEP is based upon the Mach kernel, which was originally
developed at Carnegie Mellon University, with additional kernel layers and
low-level user space code derived from select parts of BSD."_ [1]

NeXTSTEP became the basis for OS X. It meets the Single UNIX Specification
[2].

[1]
[https://en.wikipedia.org/wiki/OS_X#History](https://en.wikipedia.org/wiki/OS_X#History)

[2]
[https://en.wikipedia.org/wiki/Single_UNIX_Specification#OS_X](https://en.wikipedia.org/wiki/Single_UNIX_Specification#OS_X)

~~~
contingencies
That doesn't answer my question.

Both Android and OSX are listed under
[https://en.wikipedia.org/wiki/POSIX#Mostly_POSIX-
compliant](https://en.wikipedia.org/wiki/POSIX#Mostly_POSIX-compliant)

What I would like to know is, is there any fundamental difference in how the
two have derived from their predecessors, ie. Android kernel from the Linux
kernel and OSX's XNU kernel from the NexTSTEP/BSD kernels, specifically in
terms of compatibility concerns.

(Edit reply to below: Yes but my understanding is that the Android kernel
changed fundamental system calls, such as those used for memory allocation,
forcing everything userland to be rewritten. Is the 'two systems' of XNU you
describe not, therefore, similar in its effect on compatibility?)

~~~
ori_b
The Linux kernel has only one set of system calls. Everything you can do with
Linux, you can do through it's syscall interface. Android doesn't change this,
although it ships a different, more minimal libc.

The OSX kernel has two, due to it's bolt-on nature. Mach message passing and
BSD system calls. As far as I am aware, the BSD system calls is an emulation
layer, and is not entirely complete.

As a user, you don't care; the quirks of both systems are papered over by
libc, which does the appropriate syscall dance to create a posix compliant
system. (For an example of a Linux quirk, 'exit()' on Linux doesn't actually
exit the process, it only exits the current thread).

------
barosl
I heard from somewhere that technically, OS X does not preserve backward
compatibility for system calls, so you should use libc function's instead,
otherwise it is an undefined behavior. Whereas Linux keeps a hard
compatibility guarantee. Is that true? I guess Apple will really hesitate
before commiting breaking changes, but I'm genuinely curious if they reserve
the rights in thoery.

~~~
AdieuToLogic
> I heard from somewhere that technically, OS X does not preserve backward
> compatibility for system calls, so you should use libc function's instead,
> otherwise it is an undefined behavior.

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...](https://developer.apple.com/library/mac/qa/qa1118/_index.html)

~~~
creshal
> Not being a troll here... Why would anyone care unless they are writing a
> libc replacement?

Statically compiling the libc is common with proprietary Linux software, if I
remember correctly.

~~~
AdieuToLogic
Gotcha. I guess it's an OS expectation thing then. In OS-X, it's pretty much
an assumption that dynamic linking is what's going to happen (good or bad).

Thanks for clarifying this point for me.

~~~
creshal
Linux userland has various libcs available (klibc, glibc, eglibc, uclibc,
dietlibc, musl, …), with distributions occasionally switching between them,
and ABI-incompatible changes happen every once in a while. Source-distributed
software does not have to care usually, but for binary-only distribution,
statically compiling the libc is the easiest bet. Thus, the kernel _has_ to
maintain compatibility.

------
kentonv
Linux's syscalls: [http://man7.org/linux/man-
pages/dir_section_2.html](http://man7.org/linux/man-pages/dir_section_2.html)

(I have learned a lot by just going to that page and randomly clicking on
things.)

~~~
asveikau
This is documentation. It's not an ABI reference the same way the article is.
The article is about the nuts and bolts of how user mode makes calls into the
kernel, which manpages don't bother with.

If you want to learn the syscall ABI on Linux you need to look at
<asm/unistd.h>. Seems like this file has gone through some refactorings since
the last time I looked, but here's an older version: [http://lxr.free-
electrons.com/source/include/asm-generic/uni...](http://lxr.free-
electrons.com/source/include/asm-generic/unistd.h?v=3.2) [edit: ia32 here
[http://lxr.free-
electrons.com/source/arch/x86/include/asm/un...](http://lxr.free-
electrons.com/source/arch/x86/include/asm/unistd_32.h?v=3.2)] -- the constants
in the __NR_* macros define the table that this article is attempting to
build. [Basically, the interrupt handler for a syscall needs to know where to
jump based on that index.]

------
wavesum
Why so many duplicates? For expample int nosys() is listed 185 times, each
pointing to bsd/kern/subr_xxx.c

~~~
asveikau
Because when you remove items from that list or otherwise change the order,
you break binary compatibility.

The C library specifies the index into this table when making a syscall. You
don't want a situation where the C library and the kernel are mismatched and
disagree about what the syscalls are.

The safe way to remove a syscall is to change it to return ENOSYS. All the
syscalls that come after it in the table therefore retain the same index.

