Der Grund ist kein historischer, sondern ein praktischer. Es gibt viele, viele Programme, die auf dem Linux-Kernel laufen. Wenn eine Kernel-Schnittstelle diese Programme beschädigt, müsste jeder diese Programme aktualisieren.
Nun ist es wahr, dass die meisten Programme tatsächlich nicht direkt von Kernel-Interfaces (den Systemaufrufen ) abhängen , sondern nur von Interfaces der C-Standardbibliothek (C- Wrapper um die Systemaufrufe). Oh, aber welche Standardbibliothek? Glibc? uClibC? Dietlibc? Bionic? Musl? etc.
Es gibt aber auch viele Programme, die betriebssystemspezifische Dienste implementieren und von Kernel-Schnittstellen abhängen, die von der Standardbibliothek nicht verfügbar gemacht werden. (Unter Linux werden viele davon über /procund angeboten /sys.)
Und dann gibt es statisch kompilierte Binärdateien. Wenn ein Kernel-Upgrade einen dieser Fehler verursacht, besteht die einzige Lösung darin, sie erneut zu kompilieren. Wenn Sie die Quelle haben: Linux unterstützt auch proprietäre Software.
Selbst wenn die Quelle verfügbar ist, kann es schmerzhaft sein, alles zu sammeln. Vor allem, 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 die Leute jahrelang alte Binaries verwenden und dass ein neues Release nicht bedeutet, dass man das einfach rausschmeißen kann. 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, bei der Sie nicht nur ein anderes Programm aktualisieren müssen, um einen neueren Kernel zum Laufen zu bringen, sondern auch noch ein weiteres und ein weiteres Programm aktualisieren müssen , weil alles von einer bestimmten Version von allem abhängt.
Es ist einigermaßen in Ordnung, eine wohldefinierte Einwegabhä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 der "Kernel der letzten Monate" ist.
Aber wenn Sie eine ZWEI-WEG-Abhängigkeit haben, sind Sie geschraubt. Das bedeutet, dass Sie im Sperrschritt upgraden müssen, und das ist einfach NICHT AKZEPTIERBAR. Es ist für den Benutzer schrecklich, aber was noch wichtiger ist, es ist für Entwickler schrecklich, weil es bedeutet, dass Sie nicht "ein Fehler ist passiert" sagen und Dinge wie versuchen können, ihn mit Halbierung oder ähnlichem einzugrenzen.
Im Benutzerbereich werden diese gegenseitigen Abhängigkeiten normalerweise durch Beibehalten verschiedener Bibliotheksversionen aufgelöst. Sie dürfen jedoch nur einen Kernel ausführen, daher muss dieser alles unterstützen, was die Leute damit tun möchten.
offiziell ,
Die Abwärtskompatibilität für [Systemaufrufe für stabil erklärt] wird für mindestens 2 Jahre garantiert.
In der Praxis jedoch
Die meisten Schnittstellen (wie Syscalls) sollten sich niemals ändern und immer verfügbar sein.
Was sich jedoch häufiger ändert, sind Schnittstellen, die nur für hardwarebezogene Programme vorgesehen sind /sys. ( /procAuf der anderen Seite, die seit der Einführung von /sysnicht hardwarebezogenen Diensten so gut wie nie auf inkompatible Weise unterbrochen wurde.)
Zusammenfassend,
Das Aufteilen des Benutzerraums 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 verschiedene Anwendungen mit komplexen Abhängigkeiten. Es ist einfacher, den Kernel stabil zu halten, als Tausende von Anwendungen in Millionen verschiedener Setups auf dem neuesten Stand zu halten.