概念的には、ライブラリ関数はプロセスの一部です。
実行時に、実行可能コードとそれが依存するすべてのライブラリ（libc.soなど）のコードは、単一のプロセスにリンクされます。したがって、そのようなライブラリで関数を呼び出すと、同じリソースと権限で、プロセスの一部として実行されます。これは、自分で作成した関数を呼び出すのと同じ考え方です（PLTやトランポリン関数などの例外はありますが、必要に応じて検索できます）。
概念的には、システムコールは、コード（通常は特権を持たない）からカーネル（必要に応じて特権をエスカレートする権限を持つ）への呼び出しを行うために使用される特別なインターフェイスです。
たとえば、Linux man brk を参照してください。 Cプログラムがmallocを呼び出してメモリを割り当てると、glibcのライブラリ関数が呼び出されます。
割り当てに十分なスペースがすでにある場合プロセス内は、必要なヒープ管理を行い、メモリを呼び出し元に返すことができます。
そうでない場合、glibcはカーネルからより多くのメモリを要求する必要があります。それは（おそらく）brk glibc関数を呼び出し、次にbrk syscallを呼び出します。 syscallを介して制御がカーネルに渡されると、グローバル仮想メモリの状態を変更してメモリを予約し、それをプロセスのアドレス空間にマップできます。
役に立たない '答えに追加：
ライブラリ関数はシステムコールよりも高速であり、通常、プロセスの特権とメモリで実行されるため、権限/セキュリティに関する考慮事項は含まれていません。
一方、syscallはカーネルで実行されるため、システム内のすべてにアクセスできるため、呼び出し時に呼び出しプロセスが実行できることを制御する必要があります（ファイルを開く権限があることを確認します）。例）さらに、syscallはカーネル内にあるため、それらを呼び出すには、CPUでのコンテキストスイッチが必要です。これは、ライブラリ呼び出しを呼び出すだけに比べて非常に重いプロセスです。
シスコールは通常、監視プログラムのシステムCPU使用率として反映されます。
- lib funはコンパイラでサポートされ、syscallはOSでサポートされます
- Libcallは特定のものですが、syscallは一般的ですが、getc、lib funは一度に1文字しかアクセスできません。文字列やWordごとではありませんが、syscallを開くと、テキストファイル、バイナリファイル、その他の多くのタイプのファイルを開くことができます。
ライブラリ呼び出し-アプリケーションにリンクされたサブルーチンを呼び出します（ライブラリの追加または追加を介して）。
システムコール-OSに制御を移し（ユーザー->システムプロシージャ-> OS）、プロセッサを特権モードにします。