Sie benötigen die Linux-Kernel-Quellen, um die tatsächliche Quelle der Systemaufrufe zu sehen. Handbuchseiten enthalten, falls auf Ihrem lokalen System installiert, nur die Dokumentation der Aufrufe und nicht deren Quelle selbst.
Unglücklicherweise werden Systemaufrufe nicht nur an einer bestimmten Stelle im gesamten Kernel-Baum gespeichert. Dies liegt daran, dass sich verschiedene Systemaufrufe auf verschiedene Teile des Systems beziehen können (Prozessverwaltung, Dateisystemverwaltung usw.) und es daher nicht möglich wäre, sie getrennt von dem Teil des Baums zu speichern, der sich auf diesen bestimmten Teil des Systems bezieht.
Am besten suchen Sie nach dem SYSCALL_DEFINE[0-6] Makro. Es wird (offensichtlich) verwendet, um den angegebenen Codeblock als Systemaufruf zu definieren. Beispiel:fs/ioctl.c hat den folgenden Code:
SYSCALL_DEFINE3(ioctl, unsigned int, fd, unsigned int, cmd, unsigned long, arg)
{
/* do freaky ioctl stuff */
}
Eine solche Definition bedeutet, dass die ioctl syscall wird deklariert und nimmt drei Argumente entgegen. Die Zahl neben SYSCALL_DEFINE bedeutet die Anzahl der Argumente. Zum Beispiel im Fall von getpid(void) , deklariert in kernel/timer.c , haben wir den folgenden Code:
SYSCALL_DEFINE0(getpid)
{
return task_tgid_vnr(current);
}
Hoffe, das klärt die Dinge ein wenig auf.
Aus Sicht einer Anwendung ist ein Systemaufruf eine elementare und atomare Operation, die vom Kernel ausgeführt wird.
Das Montage-Howto erklärt, was in Bezug auf Maschinenunterricht passiert.
Natürlich macht der Kernel eine Menge Dinge, wenn er einen Syscall handhabt.
Eigentlich könnte man fast glauben, dass der gesamte Kernel-Code der Behandlung aller Systemaufrufe gewidmet ist (das stimmt nicht ganz, aber fast; aus Sicht der Anwendungen ist der Kernel nur durch Systemaufrufe sichtbar). Die andere Antwort von Daniel Kamil Kozar erklärt, welche Kernelfunktion die Behandlung einiger Systemaufrufe startet (aber sehr oft sind viele andere Teile des Kernels indirekt an Systemaufrufen beteiligt; zum Beispiel beteiligt sich der Scheduler indirekt an der Implementierung von fork weil es den untergeordneten Prozess verwaltet, der durch einen erfolgreichen fork erstellt wurde Systemaufruf).