Warum Kernel-Modesetting statt Privilegentrennung?

Das Setzen von Kernel-Modi war anfangs ziemlich schmerzhaft, aber jetzt ist es ziemlich großartig, es zu haben. Ich meine, X muss nicht als root laufen? Hochauflösende hardwarebeschleunigte Konsolen? Cooles Zeug.

Das Problem ist, dass viele UNIX-Plattformen keine modularen Kernel-Treiber haben. Hardware, die auf KMS basiert, ist jetzt hauptsächlich auf Linux beschränkt.

Meine Frage: Warum eigentlich im Kernel implementieren?

Wenn zum Festlegen der Bildschirmauflösung Hardwarezugriff erforderlich ist, verwenden Sie einen separaten privilegierten Daemon oder eine kleine setuid-Binärdatei. Dies würde den Vorteil beibehalten, den privilegierten Code zu trennen und den Anzeigeserver als eingeschränkten Benutzer ausführen zu lassen. Gleichzeitig werden die speziellen Treiberanforderungen beseitigt und die UNIX-Unterstützung erleichtert. Richtig? Oder fehlt mir hier etwas Bedeutendes?

kernel xorg drivers

— DanL4096
quelle

Das ist die Idee hinter Mikrokernel- Betriebssystemarchitekturen.

— Barmar

In diesem Fall denke ich nicht an ein Modell vom Typ Mikrokernel, sondern nur an die Portabilität zwischen unterschiedlichen Kerneln.

— DanL4096

KMS wird auch von OpenBSD und FreeBSD verwendet, und Solaris hat auch KMS in Arbeit. Auf diese Weise wird die Treiberunterstützung auch an andere Benutzer übertragen, die KMS verwenden, wenn Entwickler einen funktionierenden Treiber für Linux erstellen.

— Hspaans

Es ist eine architektonische Sache. Der Hardwarezugriff ist eine, wenn nicht DIE Aufgabe eines Kernels. Das Aufteilen der Arbeit zwischen Kernel und Benutzerbereich ist umständlich, da Sie zwei Komponenten benötigen, die tatsächlich nur eine Arbeit mit einer verschwommenen Oberfläche ausführen. Letztendlich werden Sie Arbeiten innerhalb der Domäne des Kernels ausführen, daher gibt es ein starkes Argument dafür, das Ganze in den Kernel zu stellen. Natürlich können Sie es jedoch implementieren und wo immer Sie wollen. Bei robusten Plattformen dreht sich alles um klar (!) Definierte Architekturen und Schnittstellen. Es ist alles wabbelig wackelig.

— Bananguin

Es gab eine ziemlich lange Zeit, in der verschiedene Arten von Abstürzen die Konsole in einem seltsamen Modus verließen, in dem X nicht mehr funktionierte, der Conole-Zugriff im TTY-Stil jedoch nicht wiederhergestellt wurde. IIRC GL-Beschleunigungsprobleme und Abstürze haben diese Situation häufig provoziert. KMS bedeutet, dass der Kernel weiß, wie das Problem behoben und der Status der Konsole wiederhergestellt werden kann. IOW teilweise eine Verbesserung der Benutzerfreundlichkeit. Man könnte zwar argumentieren, dass der Kernel einen Userspace-Daemon dazu auffordern könnte, aber ich denke, dass dies möglicherweise nicht immer gut funktioniert. Auch das Einfügen in den Kernel bedeutet keine Closed-Source-Schwierigkeiten.

— James Youngman

Der Kernel verwaltet bereits Netzwerkhardware, Audiohardware, Lüfter und andere Hardware. Daher ist es sinnvoll, dass Grafikhardware auch vom Kernel verwaltet wird.

— Alexander
quelle