Ist der Kernel ein Prozess?

1. Unter Linux sagen wir immer, dass der erste Prozess init(pid == 1) ist. Aber warum ist es nicht der Kernel (Startup), der das System einrichtet und den initProzess erstellt ? Ist der Kernel ein Prozess?
2. Wir wissen, dass alle User-Space-Threads beim init-Prozess verwurzelt sind. Was ist dann mit Scheduler und anderen Kernel-Dingen wie Speicherverwaltung?

Grundsätzlich verwirrt mich die Struktur des Kernels. Wenn es sich um einen Prozess handelt, handelt es sich um einen einzelnen Prozess oder besteht er aus mehreren Prozessen?

Kurze Antworten:

1. Nein, es ist kein Prozess
2. Benutzerthreads sind bei init nicht verwurzelt.

Init ist nur der erste Prozess; Es werden keine Prozesse oder Threads verwaltet. Einige davon werden mithilfe der Kernel-syscalls fork () und exec erstellt.

Ich denke, Sie haben eine trübe Vorstellung davon, was ein Prozess ist. es bedeutet nicht nur ein bisschen Code auszuführen. Ja, der Kernel wird vor init ausgeführt (und der Bootloader sogar davor). Aber ein "Prozess" hat eine spezifische Definition von:

• Läuft im User Space
• Läuft mit einer Prozess-ID
• Viele Interaktionen müssen den Kernel durchlaufen
• Alle Ressourcen müssen vom Kernel stammen
• Muss vom Kernel geplant werden

Sobald der Kernel initialisiert ist, wird init ausgeführt, das dann alle anderen Prozesse hervorruft, denen seine Konfiguration sagt.

Was # 2 angeht, ist alles Kernel-Zeug im Kernel. Stellen Sie sich den Kernel als einen großen Codebereich vor. Wieder kein Prozess, sondern ein großer Code-Blob. Teile des Kernels befassen sich mit der Speicherverwaltung, Teile davon mit dem Planen von Teilen von sich selbst (wie Treiber usw.) und Teile davon mit Planungsprozessen.

Der Kernel verhält sich überhaupt nicht wirklich wie ein Prozess. Es wird nicht eingeplant, es wird entweder im Auftrag eines Prozesses (sogenannter Prozesskontext oder Benutzerkontext) oder als Ergebnis eines Interrupts oder einer Ausnahme (sogenannter Interruptkontext) ausgeführt.

Das heißt, der Linux-Kernel erzeugt Kernel-Threads, um einige Aufgaben auszuführen oder um zu vermeiden, dass etwas im Interrupt-Kontext zu lange ausgeführt wird. .

Sie können die Kernel-Threads in der Ausgabe des psBefehls sehen. Sie sind leicht zu identifizieren: Ihr Name steht in Klammern. Einige von ihnen führen eine Instanz pro CPU aus. Die CPU wird durch eine Zahl nach einem Schrägstrich gekennzeichnet, sodass [ksoftirqd / 0] die Instanz von ksoftirqd auf CPU 0 ist.

Es gibt Konzepte in Mikrokernen, bei denen verschiedene Teile des Kernels tatsächlich Prozesse sind, bei denen der primäre Sentinel meist nur IPC verwaltet.

Linux - egal ob gut oder schlecht - ist kein Mikrokernsystem.

Nein, es ist nicht ... Kernel (und Kernel-Erweiterungen) werden direkt in den Speicher geladen. Wenn es im Kernel unsicheren Code gibt, steht nichts zwischen ihm und großen Problemen.

Abgesehen davon führt der Kernel im Grunde genommen einen Wechsel zwischen Prozessen aus. Offensichtlich ist etwas, das Prozesse ausführt, kein Prozess.

(tl; dr 1. no 2. Teil des Kernels / seiner Erweiterung)

ninjalj schrieb: "Der Kernel verhält sich überhaupt nicht wirklich wie ein Prozess. Er wird nicht geplant."

Nun, es gibt den Leerlaufprozess (im Grunde PID 0, obwohl er nirgends angezeigt wird), der geplant ist und ungefähr immer in einem lauffähigen Zustand ist.

Kontextwechsel

❖ Prozesse werden von einem gemeinsam genutzten Teil des Betriebssystemcodes verwaltet, der als Kernel bezeichnet wird

▪ The kernel is not a separate process, but rather runs as part of a user process

❖ Die Kontextumschaltung übergibt den Steuerungsfluss von einem Prozess an einen anderen und wird unter Verwendung von Kernel-Code ausgeführt

Quelle: https://courses.cs.washington.edu/courses/cse351/19su/lectures/18/CSE351-L18-processes_19su.pdf , Seite 36