Avrai bisogno dei sorgenti del kernel Linux per vedere l'effettiva fonte delle chiamate di sistema. Le pagine di manuale, se installate sul tuo sistema locale, contengono solo la documentazione delle chiamate e non la loro fonte stessa.
Sfortunatamente per te, le chiamate di sistema non sono memorizzate in una sola posizione particolare nell'intero albero del kernel. Questo perché varie chiamate di sistema possono fare riferimento a diverse parti del sistema (gestione dei processi, gestione del filesystem, ecc.) e quindi sarebbe impossibile memorizzarle separatamente dalla parte dell'albero relativa a quella particolare parte del sistema.
La cosa migliore che puoi fare è cercare il SYSCALL_DEFINE[0-6] macro. Viene utilizzato (ovviamente) per definire il dato blocco di codice come chiamata di sistema. Ad esempio, fs/ioctl.c ha il seguente codice :
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
{
/* do freaky ioctl stuff */
}
Tale definizione significa che il ioctl syscall è dichiarato e accetta tre argomenti. Il numero accanto al SYSCALL_DEFINE indica il numero di argomenti. Ad esempio, nel caso di getpid(void) , dichiarato in kernel/timer.c , abbiamo il seguente codice :
SYSCALL_DEFINE0(getpid)
{
return task_tgid_vnr(current);
}
Spero che questo chiarisca un po' le cose.
Dal punto di vista di un'applicazione, una chiamata di sistema è un'operazione elementare e atomica eseguita dal kernel.
L'Assembly Howto spiega cosa sta succedendo, in termini di istruzioni della macchina.
Ovviamente, il kernel fa molte cose quando gestisce una chiamata di sistema.
In realtà, si potrebbe quasi credere che l'intero codice del kernel sia dedicato a gestire tutte le chiamate di sistema (questo non è del tutto vero, ma quasi; dal punto di vista delle applicazioni, il kernel è visibile solo attraverso le chiamate di sistema). L'altra risposta di Daniel Kamil Kozar spiega quale funzione del kernel sta avviando la gestione di alcune chiamate di sistema (ma molto spesso, molte altre parti del kernel partecipano indirettamente alle chiamate di sistema; ad esempio, lo scheduler partecipa indirettamente all'implementazione di fork perché gestisce il processo figlio creato da un fork riuscito chiamata di sistema).