Warum unterscheiden sich die Linux-Systemrufnummern in x86 und x86_64?

Ich weiß, dass die Systemaufrufschnittstelle auf einer niedrigen Ebene implementiert ist und daher architektur- / plattformabhängiger, nicht "generischer" Code.

Ich kann jedoch nicht klar erkennen, warum Systemaufrufe in Linux-32-Bit-x86-Kerneln Nummern haben, die in der ähnlichen Architektur von Linux-64-Bit-x86_64 nicht gleich bleiben. Was ist die Motivation / der Grund für diese Entscheidung?

Meine erste Vermutung war, dass der Hintergrund darin bestand, 32-Bit-Anwendungen auf einem x86_64-System lauffähig zu halten, damit das System über einen angemessenen Versatz zur Systemrufnummer weiß, dass der Benutzerbereich 32-Bit oder 64-Bit ist beziehungsweise. Dies ist jedoch nicht der Fall. Zumindest scheint es mir, dass read () als Systemrufnummer 0 in x86_64 nicht mit diesem Gedanken in Einklang gebracht werden kann.

Eine andere Vermutung war, dass das Ändern der Systemrufnummern einen sicherheitsrelevanten Hintergrund haben könnte, was ich selbst nicht bestätigen konnte.

Da ich die Herausforderungen der Implementierung der architekturabhängigen Codeteile nicht kenne, frage ich mich immer noch, wie sich die Systemrufnummern ändern lassen , wenn es nicht nötig erscheint (da sogar ein 16-Bit-Register weitaus mehr als die derzeit ~ 346 Zahlen speichern würde, um alle darzustellen Anrufe), würde dazu beitragen, etwas anderes zu erreichen, als die Kompatibilität zu unterbrechen (obwohl die Verwendung der Systemaufrufe durch eine Bibliothek, libc, es mildert).

Was die Gründe für die spezifische Nummerierung betrifft, die mit keiner anderen Architektur übereinstimmt (außer "x32", das eigentlich nur Teil der x86_64-Architektur ist): In den frühen Tagen der x86_64-Unterstützung im Linux-Kernel gab es noch keine Aus Gründen der Abwärtskompatibilität wurden alle Systemaufrufe neu nummeriert , um sie auf der Ebene der Cacheline-Nutzung zu optimieren .

Ich weiß nicht genug über die Kernelentwicklung, um die spezifischen Grundlagen für diese Auswahlmöglichkeiten zu kennen, aber anscheinend steckt eine gewisse Logik dahinter, alles mit diesen bestimmten Zahlen neu zu nummerieren, anstatt einfach die Liste aus einer vorhandenen Architektur zu kopieren und die nicht verwendeten zu entfernen. Es sieht so aus, als ob die Reihenfolge davon abhängt, wie häufig sie aufgerufen werden - z. B. Lesen / Schreiben / Öffnen / Schließen im Vordergrund. Exit und Fork mögen "fundamental" erscheinen, aber sie werden jeweils nur einmal pro Prozess aufgerufen.

Es kann auch etwas los sein, um Systemaufrufe, die üblicherweise in derselben Cache-Zeile verwendet werden, beizubehalten (diese Werte sind nur Ganzzahlen, aber es gibt eine Tabelle im Kernel mit Funktionszeigern für jeden einzelnen, sodass jede Gruppe von 8 Systemaufrufen belegt eine 64-Byte-Cache-Zeile für diese Tabelle)

Siehe diese Antwort auf die Frage "Warum unterscheiden sich die Systemrufnummern in amd64 linux?" auf Stapelüberlauf.

Fazit: Aus Kompatibilitätsgründen ist die Systemaufrufliste stabil und kann nur wachsen. Als die x86 64-Architektur erschien, war das ABI (Argument übergeben, Rückgabewert) anders, daher nutzten die Kernel-Entwickler die Gelegenheit, Änderungen vorzunehmen, auf die lange gewartet wurde.

Kurz gesagt, weil jemand dachte, " N+1unbegründet inkompatible Methoden sind besser als NMethoden". Für historische Arches wurden die Syscall-Nummern normalerweise so gewählt, dass sie mit einigen proprietären Unix-Legacy-Versionen übereinstimmen. Aber für x86_64 konnten die Kernel-Entwickler eine beliebige Nummerierung wählen. Anstatt die einfache Wahl zu treffen und eine bestehende Nummerierung wiederzuverwenden, trafen sie die Wahl, einen neuen Standard zu erfinden. Dann machten sie es noch einmal für aarch64 und ein paar andere. Dies ist ein sich oft wiederholendes Muster in der Linux-Kernelentwicklung.