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

Question

В справочных страницах есть несколько разделов. Два из них:

2     Unix and C system calls
3     C Library routines for C programs

Например, есть getmntinfo(3) и getfsstat(2), похоже, что они делают одно и то же. Когда следует использовать что и в чем разница?

Answer 1

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

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

Answer 5

Как правило, вы всегда должны использовать версию библиотеки 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 и системными вызовами.