Все, что не является стандартом posix, может быть дополнительным системным вызовом или дополнительными функциональными возможностями библиотеки над уровнем системных вызовов. Если ваша цель - записать переносимый код-стик в posix и максимально использовать библиотеку c (в отличие от прямых системных вызовов).
Если вам просто любопытно, они довольно сильно различаются. Вам не нужно много поддерживать системные вызовы, чтобы быть posix-совместимым. Он определяет интерфейсы, которые вам нужно поддерживать, но решать, будете ли вы делать это посредством вызова ядра или перехода в общую библиотеку.
Mac OS X даже не гарантирует двоичную совместимость системных вызовов между выпусками, они считают их частными интерфейсами между системными библиотеками и ОС. То, что большинство людей считают системными вызовами, на самом деле представляют собой небольшие заглушки в динамической библиотеке, которые обращаются к ядру, и если вы делаете системные вызовы напрямую, вместо того, чтобы ссылаться на эту динамическую библиотеку и вызывать функции-заглушки, ваш код может прерваться между ОС релизов.
Эта гибкость означает, что ряд ОС реализуют системные вызовы, которые полностью отличаются от того, что им нужно для поддержки posix, а затем работают с различиями в своих библиотеках. Например, реализация многопоточности в Linux основана на системном вызове clone (), и они берут на себя большую часть бухгалтерии, чтобы интерфейс pthreads работал в своих библиотеках.
Так что, если ваша цель - реализовать стандартную библиотеку, которая не связывается ни с чем другим и работает на нескольких Unix-системах, в некоторых случаях вы можете столкнуться с некоторыми сложностями. Если ваша цель - написать что-то, связанное со стандартными библиотеками в различных Unix-системах, вы можете получить в целом унифицированный интерфейс.