Why so many duplicates? For expample int nosys() is listed 185 times, each pointing to bsd/kern/subr_xxx.c
nosys() is a stub which simply [EDIT: raises SIGSYS then] fails with ENOSYS, i.e. "syscall not implemented".
OS X BSD System Calls Reference
11–20 of 27 posts
Re: OS X BSD System Calls Reference
#12Linux's syscalls: 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.)
Re: OS X BSD System Calls Reference
#13Seeing 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...
This makes me wonder, what would this look like for plan9? http://aiju.de/misc/plan9-syscalls
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?
Re: OS X BSD System Calls Reference
#14Why so many duplicates? For expample int nosys() is listed 185 times, each pointing to bsd/kern/subr_xxx.c
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.
Re: OS X BSD System Calls Reference
#15Linux's syscalls: 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.)
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 . 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... [edit: ia32 here http://lxr.free-electrons.com/source/arch/x86/include/asm/un...] -- 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.]
Re: OS X BSD System Calls Reference
#16Earlier quoted context omitted.
"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 [2] https://en.wikipedia.org/wiki/Single_UNIX_Specification#OS_X
That doesn't answer my question. Both Android and OSX are listed under 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…
I don't know anyone involved, however, one would have to guess that it's a simple matter of people. Apple had people from NeXT. NeXT had people from CMU who worked on Mach. People work with what they are familiar with. Therefore, Apple has Mach.
They could have started from some other kernel. They didn't happen to do that. I don't think it means much.
Re: OS X BSD System Calls Reference
#17I 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.
Re: OS X BSD System Calls Reference
#18I 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.
I don't know about OS X. You're right about Linux, though, and Torvalds will descend into an angry screed if you try to break the ABI. Windows, on the other hand, does not save the numbers between releases. http://j00ru.vexillium.org/ntapi_64/ is a table showing the system call table for each given release, and how sometimes it even changes between service packs of the same released OS.
Re: OS X BSD System Calls Reference
#19I 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.
This is true - the compatibility boundary for OS X is at the link-against-libSystem layer. The actual interface between libSystem and the kernel is private to Apple and is not guaranteed to stay argument or ABI compatible. (this includes the syscall() function)
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.
Re: OS X BSD System Calls Reference
#20I 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.
> 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...