Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OS X BSD System Calls Reference

dyjakan.sigsegv.pl

Post reply on HN
Print view View original

21–27 of 27 posts

Re: OS X BSD System Calls Reference

#21

Post by AdieuToLogic »

contingencies wrote: post #7
beltex wrote: post #6

Earlier 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…

For a bit of history regarding OS-X which may answer some of your questions, Amit Singh wrote about the history of NEXTSTEP[1] and also about XNU[2].

BTW, Singh's writings regarding OS-X are exceptionally well researched, detailed, and thorough. I highly recommend them for anyone interested in OS-X/XNU internals.

HTH

1 - http://www.kernelthread.com/publications/appleoshistory/7.ht...

2 - http://www.osxbook.com/book/bonus/ancient/whatismacosx/arch_...

Re: OS X BSD System Calls Reference

#22

Post by creshal »

AdieuToLogic wrote: post #20
barosl wrote: post #17

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.

> 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…

> 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.

Re: OS X BSD System Calls Reference

#23

Post by AdieuToLogic »

creshal wrote: post #22
AdieuToLogic wrote: post #20

Earlier quoted context omitted.

> 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…

> 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.

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.

Re: OS X BSD System Calls Reference

#24

Post by justincormack »

AdieuToLogic wrote: post #23
creshal wrote: post #22

Earlier quoted context omitted.

> 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.

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.

More than that, static linking is very difficult indeed as there is not even a crt for static linking let alone libc.a, you would have to write your own.

Re: OS X BSD System Calls Reference

#25

Post by creshal »

AdieuToLogic wrote: post #23
creshal wrote: post #22

Earlier quoted context omitted.

> 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.

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.

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.

Re: OS X BSD System Calls Reference

#26

Post by kentonv »

AdieuToLogic wrote: post #20
barosl wrote: post #17

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.

> 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…

> Why would anyone care unless they are writing a libc replacement?

- 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).

Re: OS X BSD System Calls Reference

#27

Post by zurn »

AdieuToLogic wrote: post #20
barosl wrote: post #17

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.

> 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…

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

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.

Post reply on HN