Linus Benedict Torvalds ist ein finnisch-amerikanischer Softwareentwickler, der dafür bekannt ist, die Entwicklung des Linux-Kernels zu starten und aufrechtzuerhalten.
Vor kurzem beim Erörtern von Lösungen auf x86-Prozessoren, die nicht unterstützt werden Die Anleitung «cmpxchg8b», sagte Linus Torvalds, dass es an der Zeit sein könnte Machen Sie diese Anweisung obligatorisch, damit der Kernel ausgeführt werden kann und Entfernen Sie die Unterstützung für i486-Prozessoren die "cmpxchg8b" nicht unterstützen, anstatt zu "emulieren, wie" diese Anweisung auf Prozessoren funktioniert, die "niemand mehr verwendet".
Derzeit sind fast alle Linux-Distributionen, die weiterhin x86-32-Bit-Systeme unterstützen, dazu übergegangen, den Kernel mit der Option X86_PAE zu kompilieren, was die Unterstützung von "cmpxchg8b" erfordert.
Laut Linus, bzgl. der Unterstützung im Kernel haben i486-Prozessoren an Relevanz verloren, obwohl sie immer noch im Alltag zu finden sind. Ab einem bestimmten Punkt werden Prozessoren zu Museumsstücken, und für sie ist es durchaus möglich, mit "Museums" -Kernen auszukommen.
Erwähnenswert ist, dass die Entfernung der Unterstützung für den klassischen i486 die eingebetteten Quark-Prozessoren von Intel nicht betreffen wird, die, obwohl sie zur i486-Klasse gehören, zusätzliche Anweisungen enthalten, die typisch für die Pentium-Generation sind, einschließlich "cmpxchg8b".
Darüber hinaus wird erwähnt, dass dies auch für Vortex86DX-Prozessoren gilt. Die Unterstützung für i386-Prozessoren wurde vor 10 Jahren im Kernel eingestellt.
Vielleicht sollten wir in den sauren Apfel beißen und sagen, dass wir x86-32 nur mit 'cmpxchg8b' (dh Pentium und höher) unterstützen.
Befreien Sie sich von all dem „emulieren Sie 64-Bit-Atomics mit cli/sti, da Sie wissen, dass sowieso niemand SMP auf diesen CPUs hat“, und implementieren Sie ein generisches x86-32 xchg()-Setup mit dieser try_cmpxchg64-Schleife.
Ich denke, die meisten (alle?) Distributionen aktivieren sowieso bereits X86_PAE, was X86_CMPXCHG64 zu einem Teil der Grundvoraussetzung macht.
Nicht, dass ich davon überzeugt wäre, dass die meisten Distributionen heutzutage überhaupt 32-Bit-Entwicklung machen.
...
Wir haben die i386-Unterstützung 2012 abgeschafft. Vielleicht ist es an der Zeit, die i486-Unterstützung 2022 einzustellen?
Das Ende der Unterstützung für i486 könnte ein Meilenstein sein, da sich vor kurzem verschiedene Linux-Distributionen dafür entschieden haben, die Unterstützung für 32-Bit-Prozessoren einzustellen, was nicht wirklich die von vielen erwarteten Auswirkungen hatte. Denn ja, es gibt immer noch Tausende von Benutzern mit ressourcenarmen Computern, was Linux zu einer hervorragenden Option machte, um sie weiter zu verwenden, insbesondere in vielen marginalisierten Bereichen.
Und obwohl diese Art von Ausrüstung weiterhin von den Hauptdistributionen unterstützt wurde, machten ihre aktuellen Anforderungen ihre Verwendung unmöglich. Die Wahrheit ist, dass es immer noch einige Distributionen gibt, die diese Architektur weiterhin unterstützen und vor allem für die Verwendung von ressourcenarmen Computern optimiert sind.
Zum Fall des Endes der Förderung wird erwähnt, dass die Benutzer, die Systeme mit i486-Prozessoren haben, können die LTS-Versionen des Kernels verwendendie noch viele Jahre halten wird.
Andererseits ist es auch erwähnenswert der Entwickler von Linux-Treibern de código abierto für Apple AGX GPU verwendet in den Apple M1-Chips berichtet, dass hat 99,3 % der dEQP-GLES2-Suite-Tests erfolgreich bestanden, die den Grad der Unterstützung für die Spezifikation OpenGL ES 2 verifiziert.Bei der Arbeit wurden zwei Komponenten verwendet: ein in Rust geschriebener DRM-Treiber für den Linux-Kernel und ein in C geschriebener Mesa-Treiber.
Entwicklung von Controllern wird durch die Tatsache erschwert, dass Apple M1 eine eigene GPU verwendet, entwickelt von Apple, führt proprietäre Firmware aus und verwendet ziemlich komplexe gemeinsam genutzte Datenstrukturen. Es gibt keine technische Dokumentation für die GPU, und die unabhängige Treiberentwicklung verwendet Reverse Engineering von macOS-Treibern.
Der Controller de código abierto für Mesa entwickelt wurde zunächst in einer macOS-Umgebung getestet bis der für den Linux-Kernel erforderliche DRM-Treiber (Direct Rendering Manager) vorbereitet war, der es ermöglichte, den für Mesa entwickelten Treiber unter Linux zu verwenden.
Neben dem aktuellen Erfolg beim Bestehen der dEQP-GLES2-Tests erreichte Ende September der Linux-Treiber für Apple M1-Chips ein Niveau, das geeignet ist, eine Wayland-basierte GNOME-Sitzung auszuführen und die Spiele Neverball und YouTube im Firefox-Browser auszuführen.
Schließlich wenn Sie mehr darüber wissen möchtenkönnen Sie die Details in der überprüfen folgenden Link