Linux:come trovare le implementazioni delle chiamate di sistema del kernel Linux?

Sto cercando di capire come funziona una funzione, diciamo mkdir , funziona guardando il sorgente del kernel. Questo è un tentativo di comprendere gli interni del kernel e navigare tra le varie funzioni. Conosco mkdir è definito in sys/stat.h . Ho trovato il prototipo:

/* Create a new directory named PATH, with permission bits MODE.  */
extern int mkdir (__const char *__path, __mode_t __mode)
     __THROW __nonnull ((1));

Ora ho bisogno di vedere in quale file C è implementata questa funzione. Dalla directory di origine, ho provato

ack "int mkdir"

visualizzato

security/inode.c
103:static int mkdir(struct inode *dir, struct dentry *dentry, int mode)

tools/perf/util/util.c
4:int mkdir_p(char *path, mode_t mode)

tools/perf/util/util.h
259:int mkdir_p(char *path, mode_t mode);

Ma nessuno di loro corrisponde alla definizione in sys/stat.h .

Domande

1. Quale file ha il mkdir implementazione?
2. Con una definizione di funzione come quella sopra, come posso scoprire quale file ha l'implementazione? C'è qualche schema seguito dal kernel nella definizione e nell'implementazione dei metodi?

NOTA:sto usando il kernel 2.6.36-rc1.

Risposta accettata:

Le chiamate di sistema non vengono gestite come le normali chiamate di funzione. Ci vuole un codice speciale per effettuare la transizione dallo spazio utente allo spazio del kernel, fondamentalmente un po' di codice assembly inline iniettato nel tuo programma nel sito di chiamata. Anche il codice lato kernel che "cattura" la chiamata di sistema è roba di basso livello che probabilmente non è necessario comprendere a fondo, almeno all'inizio.

In include/linux/syscalls.h nella directory dei sorgenti del tuo kernel, trovi questo:

asmlinkage long sys_mkdir(const char __user *pathname, int mode);

Quindi in /usr/include/asm*/unistd.h , trovi questo:

#define __NR_mkdir                              83
__SYSCALL(__NR_mkdir, sys_mkdir)

Questo codice dice mkdir(2) è la chiamata di sistema #83. Vale a dire, le chiamate di sistema vengono chiamate per numero, non per indirizzo come con una normale chiamata di funzione all'interno del proprio programma oa una funzione in una libreria collegata al proprio programma. Il codice dell'assembly inline che ho menzionato sopra lo usa per effettuare la transizione dall'utente allo spazio del kernel, portando con sé i tuoi parametri.

Un'altra prova che le cose sono un po' strane qui è che non c'è sempre un elenco di parametri rigoroso per le chiamate di sistema:open(2) , ad esempio, può accettare 2 o 3 parametri. Ciò significa open(2) è sovraccarico, una funzionalità di C++, non di C, ma l'interfaccia syscall è compatibile con C. (Questa non è la stessa cosa della funzione varargs di C, che consente a una singola funzione di accettare un numero variabile di argomenti.)

Per rispondere alla tua prima domanda, non esiste un singolo file in cui mkdir() esiste. Linux supporta molti file system diversi e ognuno ha la propria implementazione dell'operazione "mkdir". Il livello di astrazione che consente al kernel di nascondere tutto ciò che si nasconde dietro una singola chiamata di sistema è chiamato VFS. Quindi, probabilmente vorrai iniziare a scavare in fs/namei.c , con vfs_mkdir() . Le effettive implementazioni del codice di modifica del file system di basso livello sono altrove. Ad esempio, l'implementazione ext4 è chiamata ext4_mkdir() , definito in fs/ext4/namei.c .

Per quanto riguarda la tua seconda domanda, sì, ci sono degli schemi in tutto questo, ma non una sola regola. Ciò di cui hai effettivamente bisogno è una comprensione abbastanza ampia di come funziona il kernel per capire dove dovresti cercare una particolare chiamata di sistema. Non tutte le chiamate di sistema coinvolgono VFS, quindi le loro catene di chiamate lato kernel non iniziano tutte in fs/namei.c . mmap(2) , ad esempio, inizia in mm/mmap.c , perché fa parte del sottosistema di gestione della memoria ("mm") del kernel.

Correlati:Linux:cosa significano i flag in /proc/cpuinfo?

Ti consiglio di procurarti una copia di "Understanding the Linux Kernel" di Bovet e Cesati.