Ich begann, über dieses Problem im Kontext der Etikette auf der Linux Kernel Mailing List nachzudenken. Als weltweit bekanntestes und wohl erfolgreichstes und wichtigstes freies Softwareprojekt erhält der Linux-Kernel viel Presse. Und der Gründer und Leiter des Projekts, Linus Torvalds, muss hier eindeutig nicht vorgestellt werden.
Linus sorgt gelegentlich mit seinen Flammen auf der LKML für Kontroversen. Diese Flammen haben nach eigenen Angaben häufig mit dem Durchbrechen des Benutzerraums zu tun. Das bringt mich zu meiner Frage.
Kann ich eine historische Perspektive darauf haben, warum das Brechen des Benutzerraums so eine schlechte Sache ist? So wie ich es verstehe, würde das Durchbrechen des User Space Korrekturen auf Anwendungsebene erfordern, aber ist das so schlimm, wenn es den Kernel-Code verbessert?
So wie ich es verstehe, ist die erklärte Richtlinie von Linus, dass das Nichtbrechen des Benutzerraums alles andere übertrumpft, einschließlich der Codequalität. Warum ist das so wichtig und was sind die Vor- und Nachteile einer solchen Politik?
(Es gibt eindeutig einige Nachteile einer solchen Politik, die konsequent angewandt wird, da Linus gelegentlich „Unstimmigkeiten“ mit seinen Top-Leutnants in der LKML zu genau diesem Thema hat. Soweit ich das beurteilen kann, setzt er sich in der Angelegenheit immer durch.)
Akzeptierte Antwort:
Der Grund ist kein historischer, sondern ein praktischer. Es gibt viele, viele, viele Programme, die auf dem Linux-Kernel laufen; wenn eine Kernel-Schnittstelle diese Programme kaputt macht, müsste jeder diese Programme aktualisieren.
Nun ist es so, dass die meisten Programme tatsächlich nicht direkt von Kernel-Schnittstellen (den Systemaufrufen) abhängen, sondern nur von Schnittstellen der C-Standardbibliothek (C-Wrapper um die Systemaufrufe). Oh, aber welche Standardbibliothek? Glibc? uClibC? Dietlibc? Bionisch? Muss? usw.
Aber es gibt auch viele Programme, die betriebssystemspezifische Dienste implementieren und von Kernel-Schnittstellen abhängen, die nicht von der Standardbibliothek bereitgestellt werden. (Unter Linux werden viele davon über /proc angeboten und /sys .)
Und dann gibt es statisch kompilierte Binärdateien. Wenn ein Kernel-Upgrade eines davon zerstört, besteht die einzige Lösung darin, es neu zu kompilieren. Wenn Sie die Quelle haben:Linux unterstützt auch proprietäre Software.
Selbst wenn die Quelle verfügbar ist, kann es mühsam sein, alles zu sammeln. Besonders wenn Sie Ihren Kernel aktualisieren, um einen Fehler mit Ihrer Hardware zu beheben. Leute aktualisieren ihren Kernel oft unabhängig vom Rest ihres Systems, weil sie die Hardwareunterstützung benötigen. Mit den Worten von Linus Torvalds:
Das Brechen von Benutzerprogrammen ist einfach nicht akzeptabel. (…) Wir wissen, dass Leute jahrelang alte Binärdateien verwenden, und dass das Erstellen einer neuen Version nicht bedeutet, dass Sie diese einfach wegwerfen können. Sie können uns vertrauen.
Er erklärt auch, dass ein Grund, dies zu einer strengen Regel zu machen, darin besteht, die Abhängigkeitshölle zu vermeiden, in der Sie nicht nur ein anderes Programm aktualisieren müssen, um einen neueren Kernel zum Laufen zu bringen, sondern auch ein weiteres Programm und noch eins und noch eins , weil alles von einer bestimmten Version von allem abhängt.
Es ist etwas ok, um eine wohldefinierte Einbahnabhängigkeit zu haben. Es ist traurig, aber manchmal unvermeidlich. (…) Was NICHT in Ordnung ist, ist eine wechselseitige Abhängigkeit. Wenn User-Space-HAL-Code von einem neuen Kernel abhängt, ist das in Ordnung, obwohl ich vermute, dass Benutzer hoffen würden, dass es nicht der „Kernel der Woche“, sondern eher ein „Kernel der letzten Monate“ sein würde.
Aber wenn Sie eine ZWEI-WEG-Abhängigkeit haben, sind Sie am Arsch. Das bedeutet, dass Sie im Gleichschritt upgraden müssen, und das IST einfach NICHT AKZEPTABEL. Es ist schrecklich für den Benutzer, aber noch wichtiger, es ist schrecklich für Entwickler, weil es bedeutet, dass Sie nicht sagen können, dass ein Fehler aufgetreten ist, und Dinge wie versuchen, ihn durch Halbierung oder ähnliches einzugrenzen.
Im Userspace werden diese gegenseitigen Abhängigkeiten normalerweise gelöst, indem verschiedene Bibliotheksversionen herumgehalten werden; aber Sie können nur einen Kernel ausführen, also muss er alles unterstützen, was die Leute damit machen wollen.
Verwandte:Erklärung der Sortierreihenfolge?Offiziell,
Abwärtskompatibilität für [für stabil erklärte Systemaufrufe] wird für mindestens 2 Jahre garantiert.
In der Praxis jedoch
Von den meisten Schnittstellen (wie Syscalls) wird erwartet, dass sie sich nie ändern und immer verfügbar sind.
Was sich häufiger ändert, sind Schnittstellen, die nur von Hardware-bezogenen Programmen verwendet werden sollen, in /sys . (/proc , die seit der Einführung von /sys für nicht-hardwarebezogene Dienste reserviert wurde, bricht so gut wie nie auf inkompatible Weise zusammen.)
Zusammenfassend
Das Durchbrechen des Benutzerbereichs würde Korrekturen auf Anwendungsebene erfordern
und das ist schlecht, weil es nur einen Kernel gibt, den die Leute unabhängig vom Rest ihres Systems aktualisieren möchten, aber es gibt viele, viele Anwendungen mit komplexen Abhängigkeiten. Es ist einfacher, den Kernel stabil zu halten, als Tausende von Anwendungen auf Millionen verschiedener Setups auf dem neuesten Stand zu halten.