Vous aurez besoin des sources du noyau Linux pour voir la source réelle des appels système. Les pages de manuel, si elles sont installées sur votre système local, ne contiennent que la documentation des appels et non leur source elle-même.
Malheureusement pour vous, les appels système ne sont pas stockés à un seul endroit particulier dans l'ensemble de l'arborescence du noyau. En effet, divers appels système peuvent faire référence à différentes parties du système (gestion des processus, gestion du système de fichiers, etc.) et il serait donc impossible de les stocker séparément de la partie de l'arborescence liée à cette partie particulière du système.
La meilleure chose à faire est de rechercher le SYSCALL_DEFINE[0-6] macro. Il est utilisé (évidemment) pour définir le bloc de code donné comme un appel système. Par exemple, fs/ioctl.c a le code suivant :
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
{
/* do freaky ioctl stuff */
}
Une telle définition signifie que le ioctl syscall est déclaré et prend trois arguments. Le nombre à côté du SYSCALL_DEFINE signifie le nombre d'arguments. Par exemple, dans le cas de getpid(void) , déclaré en kernel/timer.c , nous avons le code suivant :
SYSCALL_DEFINE0(getpid)
{
return task_tgid_vnr(current);
}
J'espère que cela clarifie un peu les choses.
Du point de vue d'une application, un appel système est une opération élémentaire et atomique effectuée par le noyau.
L'Assemblée Howto explique ce qui se passe, en termes d'instruction de la machine.
Bien sûr, le noyau fait beaucoup de choses lors de la gestion d'un appel système.
En fait, on pourrait presque croire que tout le code du noyau est consacré à gérer tous les appels système (ce n'est pas tout à fait vrai, mais presque; du point de vue des applications, le noyau n'est visible qu'à travers les appels système). L'autre réponse de Daniel Kamil Kozar explique quelle fonction du noyau démarre la gestion de certains appels système (mais très souvent, de nombreuses autres parties du noyau participent indirectement aux appels système ; par exemple, le planificateur participe indirectement à l'implémentation de fork car il gère le processus enfant créé par un fork réussi appel système).