Wahrscheinlich ist er nur ein Wayland-Fanboy/Entwickler und ist ein bisschen arschverletzt, dass sich die Distributionen kein Stück dafür interessieren.
Von Jörg Zweier am Di, 1. September 2009 um 20:57 #
Bei Wayland hat sich sehr lange nichts mehr im Code getan, als ich das letzte mal dort geschaut hatte. Schade, denn X.org ist veraltet und sollte schleunigst komplett abgelöst werden. Am liebsten wäre mir, wenn die ganzen Treiber komplett in den Kernel ausgelagert werden und man nur noch mit einem kleinen Client, der im User Space läuft, mit einer einheitlichen API so mit dem Kernel kommuniziert. So ähnlich war das bei Mac OS X ja auch der Fall gewesen vor einigen Jahren. Wayland scheint aber sehr viel komplexer zu sein. Ich bin jedenfalls schon beim Verständnis der ganzen Technik überfordert, weil die ganzen Artikel darüber von Begriffen wie TTM, GEM, KML, KMS vollkommen überflutet sind und mich als Anfänger in dem Segment vollkommen überfordern, zumal es auf Deutsch komischerweise gar keine Artikel darüber gibt. Jeder scheint irgendwie sein eigenes "System" zu brauchen. Wieso können nicht alle Grafikkartenhersteller gemeinsam eine einheitlichene und zugleich simple Schnittstelle erarbeiten?
Von MatratzenMatze am Di, 1. September 2009 um 21:16 #
Ja das mit Wayland ist sehr schade ! Das mit den Schnittstellen legt sich aber, TTM und GEM sind Speichermanager und die laufen im Kernel(-Modul) ab, KMS ist ne ganz feine Sache und erleichtert die Wayland/X Treiberentwicklung eher. Trotzdem, das ganze Verständniss für die Technik hat da nicht jede(r), sonst würde ich da auch gerne helfen
> Am liebsten wäre mir, wenn die ganzen Treiber komplett in den Kernel ausgelagert werden
Dann fangen sämtliche Unixe an in ihren Kerneln rumzuschmieren, weil ein paar wildgewordene Linuxfans den x-server jetzt vollständig dysfunktionalisieren? Großer Plan!
Vielleicht liegt gerade da das Problem - Wenn das grafische Subsystem von Linux Kompatibilität zu Unixen bewahren will, die sich auf dem Gebiet entwicklungstechnisch in der Steinzeit befinden, kann das ja nichts werden.
Von Anonymer Feigling am Mi, 2. September 2009 um 09:26 #
Sprich die Zukunft ist ein noch monolithischerer Kernel wo immer mehr Treiber im Kernel-Space laufen? Müssen wohl die Entwickler von ntfs-3g und FUSE (und MacFUSE) und User-Mode-Linux wohl total verpasst haben.
Ist doch richtig: DRI und KMS laufen im Kernelspace. Eine bessere Möglichkeit existiert nicht.
Bisher musste der X-Server als root laufen, um auf sonst durch den Kernel geschützte Speicherbereiche schreiben zu dürfen. Eine Auslagerung von Kernel-Funktionen in Userspace-Prozesse, die mit UID 0 laufen und /dev/mem geöffnet haben, ist keine sinnvolle Lösung. Da hätte man sie gleich im Kernel-Mode laufen lassen können. Userspace-Treiber sollten nur mit Benutzerrechten (UID > 0) lauffähig sein.
> Sprich die Zukunft ist ein noch monolithischerer Kernel wo immer mehr Treiber im Kernel-Space laufen?
Das sagt eigentlich niemand. Die Policy lautet (nach wie vor): "In den User Space kommt alles, was nicht unbedingt im Kernel sein muss und in den Kernel kommt alles, was woanders nicht erledigt werden kann." Genau das wird gemacht.
Das mit den Schnittstellen legt sich aber, TTM und GEM sind Speichermanager und die laufen im Kernel(-Modul) ab, KMS ist ne ganz feine Sache und erleichtert die Wayland/X Treiberentwicklung eher.
Trotzdem, das ganze Verständniss für die Technik hat da nicht jede(r), sonst würde ich da auch gerne helfen
Dann fangen sämtliche Unixe an in ihren Kerneln rumzuschmieren, weil ein paar wildgewordene Linuxfans den x-server jetzt vollständig dysfunktionalisieren? Großer Plan!
Bisher musste der X-Server als root laufen, um auf sonst durch den Kernel geschützte Speicherbereiche schreiben zu dürfen.
Eine Auslagerung von Kernel-Funktionen in Userspace-Prozesse, die mit UID 0 laufen und /dev/mem geöffnet haben, ist keine sinnvolle Lösung. Da hätte man sie gleich im Kernel-Mode laufen lassen können.
Userspace-Treiber sollten nur mit Benutzerrechten (UID > 0) lauffähig sein.
Das sagt eigentlich niemand. Die Policy lautet (nach wie vor): "In den User Space kommt alles, was nicht unbedingt im Kernel sein muss und in den Kernel kommt alles, was woanders nicht erledigt werden kann." Genau das wird gemacht.