Necesitará las fuentes del kernel de Linux para ver la fuente real de las llamadas al sistema. Las páginas de manual, si están instaladas en su sistema local, solo contienen la documentación de las llamadas y no su fuente en sí.
Desafortunadamente para usted, las llamadas al sistema no se almacenan en una sola ubicación en particular en todo el árbol del núcleo. Esto se debe a que varias llamadas al sistema pueden hacer referencia a diferentes partes del sistema (gestión de procesos, gestión del sistema de archivos, etc.) y, por lo tanto, no sería factible almacenarlas aparte de la parte del árbol relacionada con esa parte particular del sistema.
Lo mejor que puedes hacer es buscar el SYSCALL_DEFINE[0-6] macro. Se usa (obviamente) para definir el bloque de código dado como una llamada al sistema. Por ejemplo, fs/ioctl.c tiene el siguiente código:
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
{
/* do freaky ioctl stuff */
}
Tal definición significa que el ioctl syscall se declara y toma tres argumentos. El número al lado del SYSCALL_DEFINE significa el número de argumentos. Por ejemplo, en el caso de getpid(void) , declarado en kernel/timer.c , tenemos el siguiente código:
SYSCALL_DEFINE0(getpid)
{
return task_tgid_vnr(current);
}
Espero que eso aclare un poco las cosas.
Desde el punto de vista de una aplicación, una llamada al sistema es una operación elemental y atómica realizada por el kernel.
El Ensamblaje Howto explica lo que está sucediendo, en términos de instrucciones de máquina.
Por supuesto, el núcleo está haciendo muchas cosas al manejar una llamada al sistema.
En realidad, casi podrías creer que todo el código del kernel está dedicado a manejar todas las llamadas al sistema (esto no es del todo cierto, pero casi; desde el punto de vista de las aplicaciones, el kernel solo es visible a través de las llamadas al sistema). La otra respuesta de Daniel Kamil Kozar es explicar qué función del kernel está iniciando el manejo de alguna llamada al sistema (pero muy a menudo, muchas otras partes del kernel participan indirectamente en las llamadas al sistema; por ejemplo, el programador participa indirectamente en la implementación de fork porque administra el proceso secundario creado por un fork exitoso llamada al sistema).