В чем разница между системными вызовами C и библиотечными процедурами C?

Системные вызовы — это функции операционной системы, например, в UNIX функция malloc() построена поверх системный вызов sbrk() (для изменения размера памяти процесса).

Библиотеки — это просто код приложения, который не является частью операционной системы и часто доступен более чем в одной ОС. Они в основном такие же, как вызовы функций в вашей собственной программе.

Граница может быть немного размытой, но просто рассматривайте системные вызовы как функциональность уровня ядра.

Библиотеки общих функций построены поверх интерфейса системных вызовов, но приложения могут свободно использовать оба.

Системные вызовы похожи на ключи аутентификации, которые имеют доступ к ресурсам ядра.

Изображение выше взято из продвинутого программирования Linux и помогает понять, как пользовательские приложения взаимодействуют с ядром.

Системные вызовы — это интерфейс между кодом пользовательского уровня и ядром. Подпрограммы библиотеки C — это библиотечные вызовы, как и любые другие, просто они действительно часто предоставляются (почти повсеместно). Многие стандартные библиотечные подпрограммы являются обертками (тонкими или нет) вокруг системных вызовов, что немного стирает грань.

Что касается того, какой из них использовать, как правило, используйте тот, который лучше всего соответствует вашим потребностям.

Вызовы, описанные в разделе 2 руководства, представляют собой относительно тонкие оболочки реальных вызовов системных служб, которые перехватывают ядро. Подпрограммы стандартной библиотеки C, описанные в разделе 3 руководства, являются библиотечными функциями клиентской стороны, которые могут фактически использовать или не использовать системные вызовы.

Эта публикация имеет описание системных вызовов и перехватов в ядре (в несколько ином контексте) и объяснение основного механизма системных вызовов с некоторыми ссылками.

Как правило, вы всегда должны использовать версию библиотеки C. У них часто есть обертки, которые обрабатывают эзотерические вещи, такие как перезапуск по сигналу (если вы запросили это). Это особенно верно, если вы уже связались с библиотекой. Все правила имеют причины для нарушения. Причины использования прямых звонков,

1. Вы хотите быть libc агностиком; Возможно с установщиком. Такой код может работать на Android (bionic), uClibc и более традиционные системы glibc/eglibc, независимо от используемой библиотеки. Кроме того, динамическая загрузка с помощью оболочек для создания слоя glibc/bionic во время выполнения, позволяющего использовать двойной двоичный файл Android/Linux.
2. Вам нужна экстремальная производительность. Хотя это, вероятно, редкость и, скорее всего, ошибочно. Вероятно, переосмысление проблемы даст больше преимуществ в производительности, а отказ от обращения к системе часто является выигрышем в производительности, что иногда может делать libc.
3. Вы пишете initramfs или init код без библиотеки; чтобы создать образ меньшего размера или ускорить загрузку.
4. Вы тестируете новое ядро/платформу и не хотите усложнять жизнь полноценной файловой системой; очень похоже на initramfs.
5. Вы хотите сделать что-то очень быстро при запуске программы, но в конечном итоге хотите использовать подпрограммы libc.
6. Чтобы избежать известной ошибки в libc.
7. Функциональность недоступна через libc.

Извините, но большинство примеров специфичны для Linux, но обоснования должны применяться и к другим вариантам Unix. Последний пункт довольно распространен, когда в ядро ​​вводятся новые функции. Например, когда kqueue или epoll при первом появлении не было libc для их поддержки. Это также может произойти, если в системе установлена ​​более старая библиотека, но более новое ядро, и вы хотите использовать эту функциональность.

Если ваш процесс не использовал libc, то, скорее всего, что-то в системе будет. Кодируя свои собственные варианты, вы можете свести на нет кеш, предоставив два пути к одной и той же конечной цели. Кроме того, Unix будет совместно использовать кодовые страницы между процессами. Как правило, нет причин не использовать версию libc.

Другие ответы уже сделали звездную работу по разнице между libc и системными вызовами.