Qual è la differenza tra “C system calls” e “C library routines”?

Ci sono più sezioni nelle manpage. Due di questi sono:

 2 chiamate di sistema Unix e C
 3 routine di libreria C per i programmi C.

Ad esempio c’è getmntinfo(3) e getfsstat(2) , entrambi sembrano fare la stessa cosa. Quando si dovrebbe usare quale e qual è la differenza?

Le chiamate di sistema sono funzioni del sistema operativo, come in UNIX, la funzione malloc() è costruita sopra la chiamata di sistema sbrk() (per ridimensionare lo spazio di memoria del processo).

Le librerie sono solo codice di applicazione che non fa parte del sistema operativo e sarà spesso disponibile su più di un sistema operativo. Sono fondamentalmente le stesse chiamate di funzione all’interno del proprio programma.

La linea può essere un po ‘sfocata, ma è sufficiente visualizzare le chiamate di sistema come funzionalità a livello di kernel.

Le chiamate di sistema sono l’interfaccia tra il codice a livello utente e il kernel. Le routine di libreria C sono chiamate di libreria come tutte le altre, solo che sono comunemente fornite (praticamente universalmente). Molte routine di libreria standard sono wrapper (sottili o meno) attorno alle chiamate di sistema, che tendono a sfocare un po ‘la linea.

Per quanto riguarda quale utilizzare, come regola generale, utilizzare quella più adatta alle proprie esigenze.

Le librerie di funzioni comuni sono costruite in cima all’interfaccia di chiamata di sistema, ma le applicazioni sono libere di utilizzarle entrambe.

Le chiamate di sistema sono come chiavi di autenticazione che hanno l’accesso per utilizzare le risorse del kernel.

inserisci la descrizione dell'immagine qui

L’immagine sopra è dalla programmazione Linux avanzata e aiuta a capire come le app degli utenti interagiscono con il kernel.

Le chiamate descritte nella sezione 2 del manuale sono tutti involucri relativamente sottili attorno alle chiamate effettive ai servizi di sistema che intercettano il kernel. Le routine di libreria standard C descritte nella sezione 3 del manuale sono funzioni di libreria sul lato client che possono effettivamente utilizzare o meno le chiamate di sistema.

Questo post ha una descrizione delle chiamate di sistema e del trapping al kernel (in un contesto leggermente diverso) e spiega il meccanismo sottostante alle chiamate di sistema con alcuni riferimenti.

Come regola generale, si dovrebbe sempre usare la versione della libreria C. Spesso hanno wrapper che gestiscono cose esoteriche come riavvii su un segnale (se richiesto). Questo è particolarmente vero se sei già collegato alla libreria. Tutte le regole hanno dei motivi per essere infrante. Motivi per utilizzare le chiamate dirette,

  1. Vuoi essere libc agnostico; Forse con un programma di installazione. Tale codice potrebbe essere eseguito su sistemi Android ( bionic ), uClibc e più tradizionali glibc / eglibc, indipendentemente dalla libreria utilizzata. Inoltre, caricamento dinamico con wrapper per creare uno strato glibc / bionico run-time che consente un doppio binario Android / Linux.
  2. Hai bisogno di prestazioni estreme. Anche se questo è probabilmente raro e probabilmente errato. Probabilmente ripensare il problema darà migliori prestazioni e non chiamare il sistema è spesso una vittoria di prestazioni, che la libc può occasionalmente fare.
  3. Stai scrivendo un initramfs o un codice init senza una libreria; per creare un’immagine più piccola o avviare più velocemente.
  4. Stai testando un nuovo kernel / piattaforma e non vuoi complicare la vita con un file system completo; molto simile a initramfs .
  5. Desiderate fare qualcosa molto velocemente all’avvio del programma, ma alla fine volete usare le routine libc .
  6. Per evitare un bug noto nella libc .
  7. La funzionalità non è disponibile tramite libc .

Siamo spiacenti, la maggior parte degli esempi sono specifici per Linux, ma i razionali dovrebbero essere applicati ad altre varianti di Unix. L’ultimo elemento è abbastanza comune quando vengono introdotte nuove funzionalità in un kernel. Ad esempio, quando kqueue o epoll stato introdotto per la prima volta, non è stato supportato da libc . Questo può accadere anche se il sistema ha una vecchia libreria, ma un kernel più recente e si desidera utilizzare questa funzionalità.

Se il tuo processo non ha usato la libc , probabilmente avrà qualcosa nel sistema. Codificando le proprie varianti, è ansible annullare la cache fornendo due percorsi per lo stesso objective finale. Inoltre, Unix condividerà le code page tra i processi. Generalmente non vi è alcun motivo per non utilizzare la versione di libc .

Altre risposte hanno già fatto un lavoro stellare sulla differenza tra libc e chiamate di sistema.