Различие между системными вызовами и библиотечными функциями
Чистое решение для оболочки (который звонит cp несколько раз).
N=1000;
for i in "${srcdir}"/*; do
[ "$((N--))" = 0 ] && break
cp -t "${dstdir}" -- "$i"
done
Это копирует максимальное количество $N файлы от $srcdir кому: $dstdir. Опущены файлы, запускающиеся с точки. (И насколько я знаю, что нет никакой гарантии, что набор выбранных файлов даже был бы детерминирован.)
Концептуально, библиотечная функция является частью Вашего процесса.
Во времени выполнения Вашем исполняемом коде и коде любых библиотек (таких как libc.so) это зависит от, будьте связаны в единственный процесс. Так, когда Вы вызываете функцию в такой библиотеке, она выполняется как часть Вашего процесса с теми же ресурсами и полномочиями. Это - та же идея как вызывание функции, которую Вы записали сами (за возможными исключениями как PLT и/или функции батута, которые можно искать, если Вы заботитесь).
Концептуально, системный вызов является специальным интерфейсом, используемым для звонка из кода (который обычно непривилегирован) к ядру (который, имеет право нарастить полномочия по мере необходимости).
Например, посмотрите кирпич человека Linux. Когда программа C звонит malloc для выделения памяти это называет библиотечную функцию в glibc.
Если уже существует достаточно пространства для выделения в процессе, это может сделать любое необходимое управление "кучей" и возвратить память вызывающей стороне.
В противном случае glibc должен запросить больше памяти от ядра: это (вероятно), звонит brk функция glibc, которая в свою очередь звонит brk syscall. Только, после того как управление передало ядру через syscall, может глобальное состояние виртуальной памяти быть измененным, чтобы зарезервировать больше памяти и отобразить ее в адресное пространство Вашего процесса.
Добавление к ответу Useless:
Библиотечные функции быстрее, чем системные вызовы и обычно не содержат соображения разрешения/безопасности, когда они работают с полномочиями процесса, и это - память.
Syscalls, с другой стороны, так как они работают в ядре, имеют доступ ко всему в системе, и таким образом, они должны управлять тем, что может сделать обработка вызовов, когда это называет их (проверьте, что это имеет полномочия открыть файл, например), кроме того, так как syscalls находятся в ядре, называние их требует контекстного переключения в ЦП, который является очень тяжелым процессом относительно просто вызова вызова библиотеки.
Syscalls обычно отражаются как система использование ЦП в программах мониторинга.
- ]
[
- ]lib fun поддерживаются компилятор, в то время как syscall поддерживается операционной системой [ ] [
- ]Libcall специфичен, в то время как syscall общий, как getc a lib fun может получить доступ только к одному символу char за раз, а не к строке или слову за словом, но открыть syscall можно, используя его для открытия текстового файла. двоичный файл и многие другие типы файлов. [ ] [
вызов библиотеки - вызывают подпрограмму, соединенную в приложение (через включение или добавление библиотеки).
системный вызов - передает управление ОС (пользователь-> система proc-> ОС) и помещает процессор в привилегированный метод