Einführung

In diesem Artikel werde ich darüber sprechen, was der Mainframe mit der Fehlerverarbeitung macht und wie er sich von der Linux-Fehlerverarbeitung unterscheidet.

Der direkte Grund für das Schreiben dieses Artikels war eine Anfrage einer bestimmten Person. Ich hatte jedoch immer das Gefühl, dass die Idee einer abnormalen Verarbeitung des Hauptrahmens selbst in der heutigen Zeit, als Systeme mit PC-Servern und Clouds immer wichtiger wurden, oft hilfreich war.

Ich arbeite jetzt am Linux-Kernel, aber vor ungefähr 20 Jahren wurde ich dem Mainframe-OS-Entwicklungsteam zugewiesen und schrieb einen Treiber für einen bestimmten Coprozessor auf dem Mainframe. Es war. Zu dieser Zeit hatte ich viele Möglichkeiten, die Art und Weise zu erleben, wie man über die abnormale Verarbeitung nachdenkt, und ich hatte das Gefühl, dass die Erfahrung zu dieser Zeit auch 20 Jahre später noch sehr nützlich war.

Erstens ist der Hauptrahmen ein System, das das Fundament der Gesellschaft seit vielen Jahren stillschweigend unterstützt. Im Buchhaltungssystem der Bank, dh dem System, das das Hauptbuch Ihres Kontos führt, belegt der Hauptrahmen immer noch eine große Anzahl [^ 4]. Der Hauptrahmen wurde als System verwendet, das jeden Tag normal funktioniert und bei Problemen zu einem sozialen Problem wird. Selbst die neuesten Systeme können Hinweise darauf enthalten, was der Mainframe im Falle einer Anomalie tut. Wir hoffen, dass die Leser diesen Artikel zusammen mit dem Wort "Weiß nicht neu" lesen.

[^ 4]: Wikipedia "[Buchhaltungssystem](https://ja.wikipedia.org/wiki/%E5%8B%98%E5%AE%9A%E7%B3%BB%E3%82%B7" % E3% 82% B9% E3% 83% 86% E3% 83% A0) "

Ablehnung (über Bedingungen)

Ich hatte große Probleme und Schwierigkeiten, diesen Artikel über Begriffe zu schreiben. Mainframe-Begriffe unterscheiden sich häufig von Unix / Linux-Begriffen und haben nicht immer genau die gleiche Funktionalität.

Beispielsweise kann die IBM Mainframe-Dokumentation geschrieben werden. ikjb600 / ikj2k200_ESTAE_and_ESTAI_Exit_Routines.htm).

Die ESTAE-Exitroutine wird durch Ausgabe des ESTAE-Makrobefehls festgelegt.

ESTAE wird später beschrieben, aber das Makro bezieht sich hier auf den Prozess des Aufrufs des Systemaufrufs [^ 3] oder der Bibliotheksfunktion unter Unix / Linux. Der Name dieses Makros ist, dass das Systemsteuerungsprogramm des Hauptrahmens auf einer Assembler-Basis geschrieben ist, eine Reihe von Flüssen beim Aufrufen der Funktion als macro registriert wird und dieses Makro beim Aufrufen verwendet wird Kommt von In ähnlicher Weise kann der Begriff "Exit-Routine" für den Leser als "Handler" geeigneter sein. Auf diese Weise wird selbst das Aufrufen einer Funktion im Mainframe-Betriebssystem häufig anders aufgerufen.

Ich bin mit Begriffen wie Unix / Linux besser vertraut, deshalb schreibe ich etwas mehr dafür. Bitte beachten Sie jedoch, dass es sich nicht um eine genaue Beschreibung als Hauptrahmen handelt.

Außerdem bin ich seit fast 20 Jahren nicht mehr im Hauptrahmen, daher denke ich, dass es einige Fehler gibt. Ich würde es begrüßen, wenn Sie auf einen solchen Ort hinweisen könnten.

[^ 3]: Dies wird auch als SVC-Routine (Super Visor Call) anstelle eines Systemaufrufs im Hauptrahmen bezeichnet.

Konzept der abnormalen Verarbeitung des Hauptrahmens

Nun, zuerst werde ich die Grundidee einer abnormalen Verarbeitung des Hauptrahmens erklären. Der folgende Text beschreibt dies am besten. Dieser Text ist ein Handbuch von MVS [^ 1], dem Hauptrahmenbetriebssystem der alten IBM "Funktionen und Struktur von MVS". % 81% AE% E6% A9% 9F% E8% 83% BD% E3% 81% A8% E6% A7% 8B% E9% 80% A0-% E5% 8D% 83% E7% 94% B0-% E6 Es ist ein Auszug aus% AD% A3% E5% BD% A6 / dp / 4844372890). (Schwerpunkt Autor)

[^ 1]: Derzeit ist IBMs Mainframe-Betriebssystem z / OS, aber die Grundidee sollte sowohl für MVS als auch für z / OS gelten.

Der Hauptzweck von MVS besteht darin, die Verfügbarkeit des Systems zu maximieren und die Auswirkungen auf Benutzer im Falle eines Hardware- oder Softwarefehlers zu minimieren. Im Falle eines Fehlers versuchen wir zunächst, Arbeit und Ressourcen wiederherzustellen. Wenn dies jedoch nicht erfolgreich ist, arbeitet das gesamte System weiter __ und der Benutzer verwendet es, auch wenn der Fehlerteil vom System getrennt ist. Versuche bereit zu bleiben.

Bitte beachten Sie, dass das gesamte System hier nicht __ ist, sondern __, dass es sich um das gesamte System handelt, z. B. ein Cluster-Cluster-System. In diesem Satz geht es tatsächlich um __ "1 Hardware + 1 Betriebssystem" __ Konfiguration. Mit anderen Worten, MVS zielt auf einen __ Betrieb ab, der einen solchen __ Fehler in einem System minimiert, das ihn betreibt. Unter Linux lokalisiert der Hauptrahmen den Fehler, selbst wenn der Kernel unvermeidlich in Panik gerät, und isoliert ihn, damit das System so weit wie möglich weiterarbeitet.

Natürlich gibt es eine Grenze für das, was mit einem System getan werden kann, so dass es natürlich möglich ist, Redundanz durch Clustering sogar im Hauptrahmen durchzuführen, aber es kann gesagt werden, dass das Merkmal des Hauptrahmens darin besteht, den obigen Vorgang sogar innerhalb eines Systems anzustreben. Wahrscheinlich.

Man kann sagen, dass die Idee, die Fortsetzung des Betriebs einer Einheit so weit wie möglich zu bewerten, geboren wurde, weil der Stückpreis pro Computer in der Zeit, als der Hauptrahmen entwickelt wurde, noch hoch war.

Registrieren Sie einen Fehlerbehandlungs-Handler (ESTATE).

Um das obige Ziel zu erreichen, registrieren Sie im Hauptrahmen-Betriebssystem einen Handler für die Verarbeitung, wenn ein kritischer Fehler auftritt, und registrieren Sie einen Handler für die abnormale Verarbeitung mit dem Namen __ESTAE-Exit-Routine __ im obigen __ESTAE-Makro __. Ist fertig [^ 6]. Bei der normalen Fehlerverarbeitung wird der Fehler durch den Rückkehrcode des aufgerufenen Unterprogramms übertragen, aber im Fall eines bestimmten abnormalen Zustands registriert sich der Handler für die abnormale Verarbeitung unter Verwendung dieser Funktion namens ESTAE Es wird genannt. Die Bedeutung dieses Handlers ist möglicherweise leichter zu verstehen, wenn Sie einen Signalhandler für C-Sprachprogramme unter Unix / Linux und einen mit defer () für die Go-Sprache registrierten Handler in Betracht ziehen. Im Fall des Mainframe-Betriebssystems kann diese ESTAE-Funktion jedoch auch innerhalb des Systemaufrufs verwendet werden.

[^ 6]: Nach Angaben der Gutachter gibt es neben ESTAE auch ESPIE. (ESTAE hat einen größeren Funktionsumfang). Leider habe ich ESPIE noch nie benutzt.

Der Handler für diese Fehlerbehandlung wird in den folgenden Fällen aufgerufen.

Programmfehler. Zum Beispiel NULL-Zeigerzugriff.
Hardwarefehler. (Wenn die CPU usw. ausfällt, wird dieser Handler von einem anderen normalen Prozessor aufgerufen, wenn eine Wiederherstellung durch ECC usw. nicht möglich ist (siehe Abbildung unten).)
E / A-Fehler beim Page-In während des Paging-Vorgangs des Betriebssystems
Wenn der Bediener (Kräfte) das Jobprogramm usw. beendet.
etc.

Auf diese Weise wird es dadurch gekennzeichnet, dass es nicht nur bei Softwarefehlern, sondern auch bei Hardwareanomalien aufgerufen wird. Im Falle eines Hardwarefehlers erfolgt der Aufruf dieses Handlers in der folgenden Reihenfolge, wie in der folgenden Abbildung dargestellt.

Die CPU, die den Fehler erkennt (Maschinenprüfung), erzeugt einen Maschinenprüfungsinterrupt.
Der Machine Check Handler (MCH) bestimmt, ob eine Wiederherstellung durch ECC usw. möglich ist, und setzt die unterbrochene Verarbeitung fort, wenn eine Wiederherstellung möglich ist.
Wenn festgestellt wird, dass eine Wiederherstellung nicht möglich ist, wird ein anderer Prozessor über die Abnormalität informiert.
Der über die Anomalie gemeldete Prozessor führt den Recovery Termination Manager (RTM) aus.
RTM ruft den registrierten ESTAE-Handler auf (in dieser Abbildung nicht dargestellt).

(Die Abbildung ist ein Auszug aus "Funktionen und Struktur von MVS")

Die Merkmale von ESTAE sind wie folgt.

Mehrere ESTAE-Handler können registriert und verschachtelt werden. Wenn beispielsweise das Modul, das den ESTAE-Handler A registriert hat, ein anderes Modul aufruft und dieses Modul den ESTAE-Handler B registriert und dann ein Fehler auftritt, wird der ESTAE-Handler B aufgerufen. Sehr nützlich, wenn man bedenkt, dass Unix / Linux-Signalhandler nicht verschachtelt werden können.
Wenn in der in 1. beschriebenen Beziehung der abnormale Verarbeitungshandler des aufgerufenen Unterprogramms nicht wiederhergestellt werden kann, wird der abnormale Verarbeitungshandler des Aufrufers aufgerufen. (Dies nennt man Percoration). Es hat die Form, dass der Elternteil die Verantwortung für das Missmanagement des Kindes übernimmt (?).

Ein einfaches Diagramm dieser Situation ist wie folgt.

Registrierung von Handlern für abnormale Handhabung (FRR)

Zusätzlich zu ESTAE verfügt der Hauptrahmen über eine Funktion namens FRR. FRR kann auch einen Fehlerverarbeitungs-Handler wie ESTAE registrieren. Der Unterschied zu ESTAE besteht jedoch darin, dass MW und Apps nicht nur für das System verwendet werden können. [^ 5] Stattdessen wird der __-Handler aufgerufen, während die __-Systemsperre gedrückt gehalten wird Es ist ein Punkt. Der Vorteil ist, dass Sie sich keine Sorgen um tote Sperren machen müssen, da Sie die Sperre während der Fehlerverarbeitung nicht erneut sichern müssen, da Sie die Fehlerverarbeitung fortsetzen können, während Sie die Sperre halten.

Diejenigen, die mit der Unix / Linux-Spezifikation für asynchrone Signalsicherheit zu kämpfen haben, finden diesen Wert möglicherweise. Anstatt die "Funktionen, die im Signalhandler aufgerufen werden können" einzuschränken, ist es einfacher, sich zu erholen, wenn beim Halten der Sperre ein dedizierter Handler vorhanden ist.

Wenn ein FRR-Handler registriert ist, wird dieser Handler vor dem ESTAE-Handler aufgerufen. Dies ist eine praktische Funktion, die verwendet werden kann, wenn Ressourcen zurückgegeben werden müssen, z. B. wenn die Systemsperre zurückgegeben werden muss.

[^ 5]: Im z / OS-Handbuch "Jede Programmfunktion kann SET FRR verwenden ...". Da es als ibm.zos.v2r1.ieaa400 / setfrr.htm) geschrieben ist, kann es möglicherweise nicht nur im Systemprogramm, sondern auch in z / OS aufgerufen werden.

Was tun mit dem Anomalie-Handler?

In der Anomalie-Handling-Exit-Routine habe ich nach meiner Erfahrung beim Schreiben eines Treibers für einen Coprozessor Folgendes getan:

Zeichnen Sie Debug-Informationen auf, wenn ein Fehler auftritt
Benachrichtigung über eine Abnormalität der Komponente mithilfe der Funktion
Reparieren Sie Zeiger in Komponenten, wenn möglich
Rückgabe der verwendeten Ressourcen (Sperre, reservierter Speicher usw.)
Wenn eine Reparatur nicht möglich ist, geben Sie einen Fehler zurück, wenn die Funktion erneut aufgerufen wird.

Schauen wir uns die einzelnen nacheinander an.

1. Zeichnen Sie Debug-Informationen auf, wenn ein Fehler auftritt

Um die Ursache des Zustands untersuchen zu können, wenn später eine Abnormalität auftritt, werden wir Teilspeicherauszüge, Protokolle und Ausführungsspuren verwandter Teile sammeln. Selbst wenn es sich um einen schwierigen Zeitfehler handelt, beispielsweise um die Häufigkeit, die einmal im Jahr auftritt, handelt es sich um ein Problem, das gerade aus Sicht des Endbenutzers aufgetreten ist. In einem solchen Fall müssen Sie die Informationen zum Debuggen speichern und zur Ermittlung der Ursache verwenden. Es ist wichtig, Daten wie den internen Zustand der Komponente, in der die Abnormalität aufgetreten ist, und die zugehörige Struktur zu diesem Zeitpunkt zu erfassen.

Ich habe es als Teilspeicherauszug geschrieben, aber in dem von mir geschriebenen Treiber wurden nur die relevanten Teile wie der von diesem Treiber verwendete Speicherbereich im Speicherauszug gesammelt. Darüber hinaus wird dieser Teilabfall nach dem Sammeln nach Möglichkeit wiederhergestellt und das System wird weiter betrieben. Ich erinnere mich nicht viel an die Funktionen, die solchen Teil-Dumps im Linux-Kernel entsprechen.

(Es genügt zu sagen, dass Linux kdump am nächsten kommt, aber der ursprüngliche Zweck von kdump besteht darin, einen Speicherauszug des gesamten Systems zu sammeln, keinen Teilauszug, und es wird davon ausgegangen, dass er neu gestartet wird. )

2. Benachrichtigung über eine Abnormalität der Komponente mithilfe der Funktion

Programme, die die Funktionalität der betroffenen Komponente verwenden, sollten benachrichtigt werden, dass der Fehler aufgetreten ist. Wie oben erwähnt, ist der Hauptrahmen so konzipiert, dass das System so weit wie möglich weiter funktioniert. Wenn Sie dies nicht tun, __ "Das System funktioniert normal", aber "Für Unternehmen erforderlich". Nur die Komponente war tot "__, was der schlimmste Tod ist. In diesem Fall funktioniert die erforderliche Wiederherstellungsverarbeitung nicht, was zu schwerwiegenden Problemen führt, die das gesamte Geschäftssystem betreffen. Aus diesem Grund muss ein Rückkehrcode festgelegt werden, der angibt, dass für alle schlafenden Aufgaben ein Fehler aufgetreten ist, der auf den Abschluss der Verarbeitung der Komponente wartet, und diese Aufgabe dann aktiviert werden.

Wenn im Linux-Kernel ein Speicherfehler auftritt, ist das Beenden des Prozesses die nächste Operation, wenn der Prozess den Bereich verwendet. Im Falle eines PCIe-Fehlers ist dies jedoch nicht möglich, und es ist nur möglich, ihn im Protokoll aufzuzeichnen. (Ich denke jedoch, dass dies daran liegt, dass E / A in mehreren Schritten vom Seitencache zur Treiberschicht im Kernel unter Linux abstrahiert werden und es nicht möglich ist zu bestimmen, welche E / A mit welchem Prozess verknüpft sind. Die E / A-Schicht des Hauptrahmens ist relativ einfach, z. B. keine Caching-Schicht wie der Seiten-Cache.)

3. Reparieren Sie Zeiger in Komponenten, wenn möglich

Ich kann hier nicht zu sehr ins Detail gehen, aber ich erinnere mich, dass der Treiber, den ich geschrieben habe, reparierte Zeiger wie Linklisten innerhalb von Komponenten so weit wie möglich repariert hat. Ich erinnere mich an keinen Linux-Treiber, der dasselbe tut. Grundsätzlich besteht die Grundhaltung des Linux-Kernels darin, in Panik zu geraten, wenn dies geschieht.

4. Rückgabe der verwendeten Ressourcen

Die verwendeten Ressourcen müssen auch im Falle einer Anomalie zurückgegeben werden. Wenn Sie beispielsweise den verwendeten Speicher nicht zurückgeben, kann ein Speicherverlust auftreten und der Systemspeicher kann später leer werden. Wenn das gesamte System noch im Besitz einer Sperre ist, blockiert das System später, wenn versucht wird, die Sperre abzurufen. Auf diese Weise ist es wichtig, die in der Fehlerverarbeitungsroutine enthaltenen Ressourcen zurückzugeben. Die Ressourcen müssen ordnungsgemäß zurückgegeben werden, damit das System so lange wie möglich läuft.

5. Wenn eine Reparatur nicht möglich ist, stellen Sie so ein, dass beim erneuten Aufruf der Funktion ein Fehler zurückgegeben wird.

Trennen Sie die Komponente vom System, um zu verhindern, dass sie in einem abnormalen Zustand verwendet wird. Stellen Sie sicher, dass der Fehlerrückgabecode beim Aufruf der Komponente zurückgegeben wird.

Hauptrahmenkultur

Wenn ich über Kultur spreche, möchte ich eine kleine alte Geschichte erzählen. Die Worte, auf die meine Senioren in der Desktop-Überprüfung des Quellcodes für eine bestimmte Funktion des Hauptrahmens hingewiesen haben, wurden von mir nie vergessen. Das liegt daran, dass das Wort einen Teil der Mainframe-Kultur zu bezeichnen scheint.

Senior: "Wenn ich mir die in Assembler konvertierte Quelle anschaue, was passiert, wenn zwischen dieser Anweisung und der nächsten Anweisung eine Maschinenprüfung stattfindet (aufgrund eines Hardwarefehlers)?" ICH:"????" Senior: "(Da der FRR-Handler noch nicht registriert wurde) Die Sperre kann nicht zurückgegeben werden und das System blockiert? __ Es ist ein Fehler, also lasst uns ihn beheben! __"

Ich denke, die Zeilen, die meine Senioren für selbstverständlich hielten, zeigen, wie die Entwickler von Mainframe-Systemen auf eine anomale Handhabung hinarbeiteten.

Es ist nicht vorhersehbar, wo ein Hardwarefehler auftritt, wenn die Software ausgeführt wird. Es macht also keinen Sinn, das oben Genannte nur an einer Stelle im Code zu betrachten, den ich überprüft habe. Fast der gesamte Quellcode von oben nach unten ist als Punkt bedeutungslos, sofern solche Hardwareanomalien nicht berücksichtigt werden. Ich denke, dass die Zuverlässigkeit des Hauptrahmens wirklich beeindruckend ist, weil wir ihn mit der Einstellung implementiert haben, das System selbst bei einer derart abnormalen Verarbeitung zum Zeitpunkt eines Hardwarefehlers nicht anzuhalten, und dies auch weiterhin getan haben.

Außerdem erinnere ich mich, dass das Verhältnis des abnormalen Verarbeitungscodes zum gesamten Quellcode sehr groß war, da die abnormale Verarbeitung auf diese Weise in vollem Umfang implementiert wurde. Es tut mir leid für das persönliche Gefühl, dass n = 1 ist, aber ich habe das Gefühl, dass die normale Verarbeitung und die abnormale Verarbeitung des Hauptrahmens intuitiv in einem Verhältnis von etwa 3: 7 implementiert wurden. Ich denke, dass es mit viel Aufwand im Umgang mit Anomalien implementiert wurde. (Wenn Sie das gleiche Verhältnis wünschen, ist der Linux-Kernel ungefähr 5: 5? Wenn Sie interessiert sind, berechnen Sie bitte.)

Kritische Sicht

Bisher haben wir erklärt, was zu tun ist, wenn der Hauptrahmen abnormal ist, aber zum Schluss erklären wir die kritische Sichtweise. Einige von Ihnen haben sich nach dem Lesen der Erklärungen möglicherweise unwohl gefühlt, und ich habe viele skeptische oder kritische Meinungen gehört, seit ich in der Mainframe-Abteilung war. An den Hauptrahmen zu glauben ist keine gesunde Einstellung. Im Gegenteil, ich denke, dass das vollständige Verweigern des Hauptrahmens nicht die richtige Form für das Engineering ist.

Es ist auch wichtig, Ihre Skepsis gegenüber dem Mainframe zu kennen, um die Vor- und Nachteile moderner Architekturen, einschließlich des Mainframes und der Cloud, ruhig analysieren und die richtige Technologie auswählen zu können. Machen wir das.

"Funktioniert die abnormale Verarbeitung zum Zeitpunkt eines Hardwarefehlers überhaupt?"

Da keine Daten vorliegen, handelt es sich um eine qualitative Geschichte. Wenn der Wiederherstellungsprozess jedoch gut funktioniert, wenn ein CPU-Fehler auftritt, kann selbst der Hauptrahmen nicht wie erwartet wiederhergestellt werden. Es scheint ziemlich viele zu geben. Schließlich handelt es sich bei Hardwarefehlern häufig um Pulpunte, die nicht wissen, was passieren wird, und es scheint schwierig zu sein, die Wiederherstellungsverarbeitung auch mit dem Hauptrahmen, der dies tut, gut durchzuführen. Ist es aus diesem Grund sinnvoll, bisher hart am Wiederherstellungsprozess zu arbeiten? Da ist auch die Idee.

Persönlich, auch wenn es nicht ideal funktioniert, ist es nicht verwunderlich, dass ich stolz sagen kann: "Die Software wurde entwickelt, um sich bisher zu erholen", aber die Technologie Die Meinungen darüber, ob dies sinnvoll ist oder nicht, werden geteilt.

(Hinzugefügt am 2020/5/3 20:00) Ich habe einen Kommentar auf Facebook erhalten. Ich habe die Erlaubnis erhalten, daher werde ich sie auch hier hinzufügen.

Die Frage ist: "Funktioniert die abnormale Verarbeitung zum Zeitpunkt eines Hardwarefehlers überhaupt?", Aber als ich auf einem Allzweckcomputer arbeitete, ・ Anstatt "Hardwarefehler zu vermeiden", sollten Sie "Informationen hinterlassen, um die Situation von Problemen während des Betriebs" erklärbar "zu machen. "" ・ "Weil es wichtig ist, in der Berufswelt rechenschaftspflichtig zu sein." ・ "Erkennen Sie zunächst, dass Best Effort nicht zulässig ist." ・ "Daher werden auch die Aufgabenverknüpfungen verdreifacht, und die vergangenen Zustandsübergänge und die Faktoren, die die Übergänge verursacht haben, bleiben erhalten." ・ "Zu diesem Zweck ist es notwendig, Hardwarefehler zu vermeiden und Informationen zu hinterlassen." Wurde unterrichtet. für Ihre Information.

"Ist es glaubwürdig, sich auf einem System zu erholen, das behauptet, abnormal zu sein?"

Ist der Bericht über eine Anomalie überhaupt vertrauenswürdig? Es gibt eine Meinung. Anstatt der Geschichte von jemandem zu vertrauen, der behauptet, "Ich bin verrückt" vom Chef der nächsten Abteilung zu sein, ist es richtiger, wenn sich eine andere normale Person erholt? Daher ist es seltsam, dass sich das System, das die Abnormalität verursacht hat, mit ESTAE oder FRR von selbst erholt. Der Wiederherstellungsprozess sollte von einem anderen Knoten aus durchgeführt werden. " Dies ist keine falsche Meinung, und tatsächlich zielen einige Systeme darauf ab, den so entworfenen Mainframe zu ersetzen.

Natürlich wirft die Wiederherstellung durch andere Systeme ein anderes Problem auf. Ich werde nicht viel über die Schwierigkeit der Wiederherstellung mit Clustering oder verteilten Systemen sprechen, da die Leser davon vielleicht besser vertraut sind, aber es scheint keine absolute Lösung zu geben. Schließlich ist "Wie weit und wie wird die Wiederherstellungsverarbeitung im Falle einer Anomalie durchgeführt?" Die einzige Möglichkeit, die technischen und monetären Kosten und Auswirkungen zu vergleichen und die entsprechende zu übernehmen. nicht.

Zusammenfassung

Beschrieb das Konzept und den Inhalt einer abnormalen Verarbeitung des Hauptrahmens. Ich habe auch so viel hinzugefügt, wie ich darüber schreiben kann, was Linux dafür tut. Ich hoffe, es wird dem Leser hilfreich sein.

Verweise

["Funktion und Struktur von MVS" Modern Science Co., Ltd. (Impress) ISBN-13: 978-4844372899](https://www.amazon.co.jp/%EF%BC%ADVS%E3%81%AE%E6% A9% 9F% E8% 83% BD% E3% 81% A8% E6% A7% 8B% E9% 80% A0-% E5% 8D% 83% E7% 94% B0-% E6% AD% A3% E5% BD% A6 / dp / 4844372890)

[LINUX] Fehlerbehandlung im Hauptrahmen