: „Wir zerstören den Benutzerraum nicht“, aber ihre Bedeutung ist möglicherweise nicht jedem klar, der sie hört. Diese „Erste Regel“ erinnert Entwickler an die Stabilität des Application Binary Interface (ABI), das für die Kommunikation und Konfiguration zwischen Anwendungen und dem Kernel verwendet wird. Das Folgende soll den Leser mit ABI-Konzepten vertraut machen, erklären, warum ABI-Stabilität wichtig ist, und diskutieren, was in einem stabilen Linux-ABI enthalten ist. Das kontinuierliche Wachstum und die Weiterentwicklung von Linux erforderten Änderungen am ABI, von denen einige umstritten waren.
als API betrachtet. Programme, die die Bibliothek aufrufen oder Daten im String-Format austauschen, müssen sich an die in der API beschriebenen Konventionen halten, andernfalls kann es zu unerwarteten Ergebnissen kommen. ABIs ähneln APIs darin, dass sie festlegen, wie Befehle interpretiert und Binärdaten ausgetauscht werden. Für C-Programme umfasst der ABI typischerweise den Rückgabetyp und die Argumentliste von Funktionen, das Layout von Strukturen sowie die Bedeutung, Reihenfolge und den Umfang der Aufzählungstypen. Ab 2022 besteht der Linux-Kernel immer noch fast ausschließlich aus C-Programmen und muss sich daher an diese Spezifikationen halten.
Die Stabilitätsgarantie des Linux ABI von Torvalds selbst ermöglicht es Linux-Distributionen und einzelnen Benutzern, den Kernel selbstständig zu aktualisieren, ohne vom Betriebssystem beeinträchtigt zu werden.
Wenn Linux kein stabiles ABI hätte, müssten die meisten oder sogar das gesamte Betriebssystem jedes Mal neu installiert werden, wenn der Kernel gepatcht werden müsste, um ein Sicherheitsproblem zu beheben. Die Stabilität der Binärschnittstelle ist eindeutig einer der wichtigen Faktoren für die Benutzerfreundlichkeit und weite Verbreitung von Linux.
Die Linux-ABI-Stabilitätsgarantie funktioniert in den meisten Fällen gut. Laut
Smart Meter und Intelligentes Parksystem Solche gewöhnlichen Produkte verwenden möglicherweise eine 32-Bit-Prozessorarchitektur und unterstützen möglicherweise keine Software-Updates. Der Linux-Kernel hat intern auf die Verwendung von 64-Bit umgestellt -indent: 0px; display: inline-block;">time_t Undurchsichtiger Datentyp, um einen späteren Zeitpunkt darzustellen. Das bedeutet so etwas wie time() wurden die Funktionssignaturen auf 64-Bit-Systemen geändert. Das Ausmaß dieser Bemühungen lässt sich deutlich an Kernel-Header-Dateien wie time_types.h erkennen, wo Place new und _alte Version der Datenstruktur.
🎜🎜🎜Kilometerzähler-Umdrehung🎜🎜🎜Das Glibc-Projekt 🎜unterstützt auch 64-Bit-Zeit🎜, Sie sind also bereit, oder? Basierend auf Diskussionen auf der 🎜Debian-Mailingliste🎜 ist dies leider nicht der Fall. Distributionen stehen vor der schwierigen Entscheidung, entweder zwei Versionen aller Binärpakete für 32-Bit-Systeme oder zwei Versionen für Installationsmedien bereitzustellen. Im letzteren Fall müssen Benutzer mit 32-Bit-Versionen ihre Anwendungen neu kompilieren und neu installieren. Wie immer bereiten proprietäre Anwendungen echte Kopfschmerzen. 🎜Was genau ist in der stabilen Linux-ABI enthalten?
Stabiles ABI zu verstehen ist etwas schwierig. Zu bedenken ist, dass die meisten sysfs zwar ein stabiles ABI sind, die Debug-Schnittstellen jedoch definitiv instabil sind, weil sie Kernel-Interna dem Benutzerraum zugänglich machen. Linus Torvalds sagte einmal: „Brechen Sie den Userspace nicht kaputt“, und damit meinte er normalerweise den Schutz gewöhnlicher Benutzer, die „nur wollen, dass es funktioniert“, und nicht Systemprogrammierer und Kernel-Ingenieure, die in der Lage sein sollten, die Kernel-Dokumentation und den Quellcode zu lesen, um sie zu verstehen Was hat sich zwischen den Versionen geändert? Das Bild unten verdeutlicht diesen Unterschied.
Stabilitätsgarantien
Es ist unwahrscheinlich, dass der durchschnittliche Benutzer mit instabilen Teilen der Linux-ABI interagiert, Systemprogrammierer können dies jedoch unbeabsichtigt tun. Außer /sys/kernel/debug Außer sysfs (/sys) und procfs (/proc /sys/kernel/debug 以外，sysfs（/sys）和 procfs（/proc）的所有部分都是稳定的。
那么其他对用户空间可见的二进制接口如何呢，包括 /dev 中的设备文件、内核日志文件（可通过 dmesg
Was ist mit anderen binären Schnittstellen, die im Benutzerbereich sichtbar sind, einschließlich Gerätedateien und Kernel-Protokolldateien in /dev (Zugriff über dmesg command to read), file system metadata or in What about die „Boot-Parameter“, die in der „Befehlszeile“ des Kernels bereitgestellt werden (sichtbar in Bootloadern wie GRUB oder u-boot)? Natürlich „es kommt darauf an.“ Alte Dateisysteme mountenNeben der Tatsache, dass ein Linux-System beim Booten hängt, ist die Unfähigkeit, ein Dateisystem zu mounten, das Enttäuschendste. Befindet sich das Dateisystem auf der SSD eines zahlenden Kunden, ist das Problem wirklich gravierend. Ein Linux-Dateisystem, das unter einer älteren Kernel-Version gemountet werden konnte, sollte auch dann noch gemountet werden können, wenn der Kernel aktualisiert wird, oder? Tatsächlich „es kommt darauf an.“ Im Jahr 2020 beschwerte sich
ein verletzter Linux-Entwickler auf der Mailingliste des Kernels:
Der Kernel hat dies als gültiges mountbares Dateisystemformat ohne Fehler oder Probleme jeglicher Art akzeptiert. Warnung, und arbeitet seitdem zuverlässig auf diese Weise Jahre... Ich bin im Allgemeinen davon ausgegangen, dass das Mounten eines vorhandenen Root-Dateisystems in den Bereich des Kernel<->Userspace oder der Kernel<-> bestehenden Systemgrenzen fällt, wie durch das Aktualisieren des Kernels mit vorhandenen Benutzerbereichen und kompatibel sein Systeme, definiert durch das, was vom Kernel akzeptiert und von vorhandenen Benutzerbereichen erfolgreich verwendet wird.
Aber es gibt ein Problem: Diese nicht mountbaren Dateisysteme werden mit einem proprietären Tool erstellt, das auf Flags basiert, die vom Kernel definiert, aber nicht vom Kernel verwendet werden. Dieses Flag erscheint nicht in den API-Headern oder procfs/sysfs von Linux, sondern ist ein Implementierungsdetail. Daher bedeutet die Interpretation dieses Flags im User-Space-Code, sich auf „Undefiniertes Verhalten“ zu verlassen, eine Phrase, die fast jeden Softwareentwickler zum Schaudern bringt. Als die Kernel-Community ihre internen Tests verbesserte und begann, an neuen Konsistenzprüfungen zu arbeiten, begann der Systemaufruf „man 2 mount
“ plötzlich, Dateisysteme mit proprietären Formaten abzulehnen. Da der Ersteller des Formats eindeutig ein Softwareentwickler war, gelang es ihm nicht, die Sympathie der Betreuer des Kernel-Dateisystems zu gewinnen. 
Auf dem Bauschild steht, dass Teams an den Bäumen arbeiten
🎜Thread-Kernel-Dmesg-Protokoll
Ist das Dateiformat im Verzeichnis /dev garantiert stabil oder instabil? dmesg-Befehl /dev 目录中的文件格式是否保证稳定或不稳定？dmesg 命令 会从文件 /dev/kmsg 中读取内容。2018 年，一位开发人员 为 dmesg 输出实现了线程化，使内核能够“在打印一系列 printk() 消息到控制台时，不会被中断和/或被其他线程的并发 printk() 干扰”。听起来很棒！通过在 /dev/kmsg 输出的每一行添加线程 ID，实现了线程化。密切关注的读者将意识到这个改动改变了 /dev/kmsg 的 ABI，这意味着解析该文件的应用程序也需要进行相应的修改。由于许多发行版没有编译启用新功能的内核，大多数使用 /bin/dmesg 的用户可能没有注意到这件事，但这个改动破坏了 GDB 调试器 读取内核日志的能力。
确实，敏锐的读者会认为 GDB 的用户运气不佳，因为调试器是开发人员工具。实际上并非如此，因为需要更新以支持新的 /dev/kmsg liest aus der Datei /dev/kmsg>. Im Jahr 2018 implementierte ein Entwickler Threading <a target="_blank" href="https://www.php.cn/link/50d2e70cdf7dd05be85e1b8df3f8ced4"> für die dmesg-Ausgabe, wodurch der Kernel „eine Reihe von printk()</a> Wenn die Nachricht an die Konsole gesendet wird, wird sie nicht von anderen Threads unterbrochen und/oder bestätigt printk() Interferenz". Klingt großartig! Von /dev/kmsg Fügt jeder Ausgabezeile eine Thread-ID hinzu, um Threading zu erreichen. Wer genau hinschaut, wird feststellen, dass sich durch diese Änderung /dev/kmsgs ABI, was bedeutet, dass die Anwendung, die die Datei analysiert, ebenfalls entsprechend geändert werden muss. Da viele Distributionen den Kernel nicht mit aktivierten neuen Funktionen kompilieren, verwenden die meisten /bin/dmesg Benutzer bemerken dies möglicherweise nicht, aber diese Änderung unterbricht GDB-Debugger Die Möglichkeit, Kernel-Protokolle zu lesen.
In der Tat werden kluge Leser denken, dass Benutzer von GDB Pech haben, weil der Debugger ein Entwicklertool ist. Dies ist eigentlich nicht der Fall, da es aktualisiert werden muss, um das neue /dev/kmsg Der Code im Format befindet sich im „in-tree“-Teil des Git-Quellcode-Repositorys des Kernels. Bei einem normalen Projekt wäre es ein offensichtlicher Fehler, wenn Programme innerhalb einer einzelnen Codebasis nicht zusammenarbeiten würden. Daher wurde ein
Patch eingefügt, der es GDB ermöglicht, mit Threaded /dev/kmsg zusammenzuarbeiten. Was ist mit BPF-Programmen? BPF ist ein leistungsstarkes Tool, das im laufenden Kernel überwacht und sogar in Echtzeit konfiguriert werden kann. BPF wurde ursprünglich entwickelt, um die Netzwerkkonfiguration in Echtzeit zu unterstützen, indem es Systemadministratoren ermöglicht, Paketfilter im Handumdrehen über die Befehlszeile zu ändern. Alexei Starovoitov und andere haben BPF stark erweitert, um beliebige Kernelfunktionen verfolgen zu können. Die Ablaufverfolgung ist eindeutig die Domäne von Entwicklern und nicht von normalen Benutzern und unterliegt daher offensichtlich keinen ABI-Garantien (obwohl der Systemaufruf bpf()
die gleichen Stabilitätsversprechen hat wie andere Systemaufrufe). Andererseits eröffnet die Erstellung von BPF-Programmen mit neuer Funktionalität die Möglichkeit, „Kernelmodule als De-facto-Standardmittel zur Erweiterung des Kernels zu ersetzen“. Kernel-Module sorgen dafür, dass Geräte, Dateisysteme, Verschlüsselung, Netzwerke usw. ordnungsgemäß funktionieren. Dies sind natürlich auch Einrichtungen, auf die sich der durchschnittliche Benutzer verlässt, der „einfach nur möchte, dass es funktioniert“. Das Problem besteht darin, dass BPF-Programme im Gegensatz zu den meisten Open-Source-Kernelmodulen traditionell nicht im Kernel-Quellcode enthalten sind. Im Frühjahr 2022 geriet ein Vorschlag
in den Fokus, der vorsah, Unterstützung für eine breite Palette von Human-Interface-Geräten (wie Mäusen und Tastaturen) mithilfe von Mini-BPF-Programmen anstelle von Gerätetreiber-Patches bereitzustellen. Es folgte eine lebhafte Diskussion, aber das Problem wurde offenbar in Torvalds‘ Kommentaren
beim Open Source Summit gelöst: 🎜 Er weist darauf hin, dass Sie das Problem beheben müssen, wenn Sie „echte Userspace-Tools, die von normalen (Nicht-Kernel-Entwickler-)Benutzern verwendet werden“ beschädigen, unabhängig davon, ob eBPF verwendet wird oder nicht.
Es scheint sich ein Konsens darüber abzuzeichnen, dass Entwickler, die möchten, dass ihre BPF-Programme nach einem Kernel-Update weiterhin funktionieren, sie an einem noch nicht festgelegten Ort im Kernel-Quellcode-Repository festschreiben müssen. Bleiben Sie auf dem Laufenden, um zu sehen, welche Richtlinien die Kernel-Community in Bezug auf BPF- und ABI-Stabilität übernimmt.
FazitDie ABI-Stabilitätsgarantien des Kernels gelten für procfs, sysfs und die Systemaufrufschnittstelle, es gibt jedoch wichtige Ausnahmen. Wenn eine Kernel-Änderung „In-Tree“-Code oder eine Userspace-Anwendung beschädigt, wird der fehlerhafte Patch oft schnell zurückgesetzt. Bei proprietärem Code, der auf Kernel-Implementierungsdetails basiert, sind diese Details zwar vom Benutzerbereich aus zugänglich, aber nicht geschützt und erfährt nur begrenztes Mitgefühl, wenn etwas schief geht. Wenn Probleme wie Y2038 einen ABI-Bruch nicht verhindern können, erfolgt der Übergang auf möglichst bewusste und systematische Weise. Und neue Funktionen wie BPF-Programme werfen unbeantwortete Fragen zu den Grenzen der ABI-Stabilität auf. DANKEVielen Dank an Akkana Peck, Sarah R. Newman und Luke S. Crawford für ihre hilfreichen Kommentare zu früheren Versionen des Materials.
Das obige ist der detaillierte Inhalt vonErfahren Sie in zehn Minuten mehr über Linux ABI. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
.
Y2038: Ein Beispiel für einen ABI-Bruch unter Berücksichtigung der derzeit laufenden, langsam auftretenden 
