Treiber müssen bei Linux RAUS AUS DEM KERNEL!

[Lala Satalin Deviluke]

Dann würden sich auch nVidia und Intel bereiterklären vernünftige und stabile Treiber für Linux zu entwickeln...

Grüße vom Planeten Deviluke!

[chrulri]

Und wo sollen sie dann hin? In den Userspace?

[nille02]

Lala Satalin Deviluke schrieb:
--------------------------------------------------------------------------------
> Dann würden sich auch nVidia und Intel bereiterklären vernünftige und
> stabile Treiber für Linux zu entwickeln...

Zuerst halte Intel da raus. Deren Foss Treiber sind Stabil.
Die Treiber gehören in den Kernel aber die Foss Treiber sollen bitte nicht mehr im Kernel Tree entwickelt werden.

[Thaodan]

Acht das macht Luke doch ganz easy.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[chrulri]

Warum denn nicht? Die gehören genauso in den Mainline Kernel Tree wie alle anderen Treiber auch.

[Lala Satalin Deviluke]

Als Treiber-Module, wie bei Windows?

Grüße vom Planeten Deviluke!

[Thaodan]

Lala Satalin Deviluke schrieb:
--------------------------------------------------------------------------------
> Als Treiber-Module, wie bei Windows?
Das sind sie sofern sie nicht klassisch eingebaut werden beim bauen schon lange.

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[nille02]

chrulri schrieb:
--------------------------------------------------------------------------------
> Warum denn nicht? Die gehören genauso in den Mainline Kernel Tree wie alle
> anderen Treiber auch.

Weil es nun erheblich schwerer ist den Treiber zurück zu portieren. Das war vorher erheblich einfacher.

[chrulri]

Man kann beim Kernel konfigurieren wählen ob man Treiber [x] (builtin) oder [m] (als Kernelmodul) gelinkt haben möchte. Kernelmodule sind trotzdem Teil des Kernels denn sie laufen wie der Kernel selbst im Kernelspace. Und das tun sie auch unter Windows, darum führen Bugs in Treibern auch unter Windows 7 noch zum Bluescreen und unter Linux zur Kernel panic.

[chrulri]

Zurück auf was portieren?

[nille02]

chrulri schrieb:
--------------------------------------------------------------------------------
> Zurück auf was portieren?

Ältere Kernel. Zur Zeit musst du zwangsweise einen neuen Kernel nutzen.

[chrulri]

Und warum sollte das mit externen Trees einfacher sein als im Mainline? Wenn sich die API im Mainline ändert, wird sich diese auch im externen Tree (= Klon + Changeset) entsprechend ändern, sodass der Treiber den neuen Kernel unterstützt womit also wieder selber zurückportiert werden muss da der Treiber nun inkompatibel zu älteren Versionen wurde.

Es ist Sache der Maintainer des Treibers zu schauen, dass der LTS aufrechterhalten wird. Wenn der Treiber neue APIs/Features der neuen Kernel verwendet ist es logischerweise umso schwerer ihn zurückzuportieren.

Das alles hat aber nichts mit externer vs. Mainline zu tun.

[Thaodan]

War das nicht gerade das was der NT Kernel als Hybrid Kernel können sollte?

Wahrung der Menschenrechte oder Freie fahrt am Wochenende.
-- Georg Schramm

[nille02]

chrulri schrieb:
--------------------------------------------------------------------------------
> Und warum sollte das mit externen Trees einfacher sein als im Mainline?

Weil es früher nur ein einfaches make und make install war. jetzt muss ich gleich einen neuen Kernel benutzen.

> Wenn sich die API im Mainline ändert, wird sich diese auch im externen Tree
> (= Klon + Changeset) entsprechend ändern, sodass der Treiber den neuen
> Kernel unterstützt womit also wieder selber zurückportiert werden muss da
> der Treiber nun inkompatibel zu älteren Versionen wurde.

Die API ändert sich nicht sonderlich oft.

> Das alles hat aber nichts mit externer vs. Mainline zu tun.

Doch für den user ist es nun so wie es ist komplizierter. Neben bei wurde auch so das Kernel Modul für die *BSDs abgewürgt. Das alles wurde früher zusammen Entwickelt.

[wasdeeh]

Thaodan schrieb:
--------------------------------------------------------------------------------
> War das nicht gerade das was der NT Kernel als Hybrid Kernel können sollte?


Nein.

[chrulri]

Achso. Das Zurückportieren ist hier also nicht das Problem sondern das Extrahieren des Treibers aus dem neuen Kernel um ihn in den alten Kernel zu kopieren. Da die API (wie du sagst) sich nicht ändert, ist es lediglich mühsam an die Sourcen überhaupt ranzukommen.

Ok, einverstanden. Jedoch bevorzuge ich im Mainline Tree gewartete Treiber, denn dann kann ich einfach einen neuen Kernel verwenden und es läuft, anstatt mit make / make install under irgendwelchem Gewurstel rumzuwuseln bis es läuft. Aber das liegt wohl daran, dass ich bei Gentoo sowieso immer auf dem (beinahe) neusten Kernel sitze.

[M.P.]

Die grafische Oberfläche ist bei einigen Windows-Versionen im Userspace

http://de.wikipedia.org/wiki/Windows_NT


"In den ersten NT-Versionen läuft das GDI zusammen mit den anderen Subsystemen auf Ring 3 der Intel-Privilegstufe außerhalb des Kernel-Bereichs. Dadurch ist der Betriebssystemkern selbst vor Abstürzen in den Programmen geschützt. Ab NT 4.0 läuft das Grafiksubsystem aus Geschwindigkeitsgründen teilweise direkt im Betriebssystemkern, womit Fehler in Grafiktreibern moderne Windows-NT-Versionen zum Absturz bringen können. Windows Vista verwendet mit dem neuen Grafiktreiber-Modell allerdings wieder Userspace-Treiber."

[chrulri]

M.P. schrieb:
--------------------------------------------------------------------------------
> Windows Vista verwendet mit dem neuen Grafiktreiber-Modell
> allerdings wieder Userspace-Treiber."

Entweder hat das mit Win7 wieder geändert oder aber nVidia Treiber haben Superkräfte mit denen sie Win7 zum Bluescreen zwingen können.