Einerseits ist es ja gut, dass "schlechter" Code entfernt wird. Andererseits steht man doof da, wenn man keinen Treiber für seine Hardware hat. Dann doch lieber einen schlechten Treiber, als gar keinen Treiber. Man könnte ihn ja aus der default Konfiguration ausschließen. So würde wenigstens noch die Möglichkeit bestehen an den Treiber zu kommen. Und ob jetzt die Kernel-Sourcen ein paar kB größer sind, halte ich persönlich für nicht so schlimm. Oder hat das noch andere Auswirkungen?
Völlig unverständlich das einige Treiberentwickler Code liegen lassen, bei dem vorzüglich dokumentierten API für Kerneltreiber und dem ultrasoliden ABI. Undankbares Volk!
Wenn jemand einen Treiber für Linux programmiert, hat er dann Zugriff auf das gesamte System? Stichwort Administratorrechte. Wäre es möglich über einen schlecht programmierten Treiber Hintertüren einzubauen?
Wuahahahahahahahahahahaha... Noch vor einem Jahr rief GKH die Leute auf ihm Treiber zuzusenden, damit sich andere darum kümmern können. Danach beschwerte er sich, wie immer medienwirksam, dass rund 300 Entwickler bereit stehen und keiner aber seine ah so tolle Idee nutzt. Vor gerade mal ein paar Wochen auf dem LinuxTag meinte jemand während der Podiumsdiskussion, dass jeder Hersteller seine Treiber an die Staging-Leute zusenden soll, damit sie sich darum kümmern können. Zitat: Jeder Code, der öffentlich gemacht wurde ist besser, als Code, der auf jemands Festplatte vergammelt.
Und nun? Alles Blödsinn! Wir rudern mal flott in die andere Richtung...
Da fällt mir nun mal unsere kleine Geschichte auf. Es gab mal eine Firma, die Chips herstellte. Da sie sich auch der OpenSource-Idee verschrieben hat, hat sie schon sehr früh Treiber für den Linux-Kernel geschrieben - es war im Jahre 2000 oder noch früher, als Linux 2.2 aktuell war. Sie pflegte die Treiber, gab Patches heraus und selbstverständlich lizenzierte sie alles unter der GPL.
Doch dann kam das Jahr 2007 oder so und ein gewisser Herr Kroah-Hartman wurde bei uns vorstellig. Jedem Herrn fiel auf, dass die Treiber der Firma Funktionen und Strukturen hatte, die nicht wirklich mit dem Kernel konform waren. Die Firma machte den blödsinnigen Fehler, den Treiber nicht direkt für Linux zu entwickeln, sondern hatte, wie es bei anderen Treibern üblich ist, einen Common- und einen Linux-Code. Der Common-Code stellte die Basis für alle ihre Treiber dar und so konnte sie Problemlos nicht nur ältere Linux-Versionen, sondern auch BSD und andere Systeme unterstützen. Das gefiel aber Herrn Kroah-Hartman nicht und so befahl er, sich im Ton entsprechend vergriffen zu haben, der Firma den Treiber umzuschreiben. Nicht der Stabilität wegen und auch nicht der falschen oder fehlenden Funktionen, sondern nur dem Stil wegen. Der Treiber musste angepasst und bereinigt werden. Im Falle der Zuwiederhandlung drohte er mit der Entfernung.
Da unsere Helden-Firma nun nicht Intel heißt, es sich nicht leisten kann mehrere verschiedene Treiber für den Linux-Kernel zu unterhalten und nicht wirklich gegen das Macho-Gehabe des Herrn Kroah-Hartman ankam, geschah das, was geschehen musste. Der Treiber wurde im Kernel von einem armen Tropf so abgeändert, dass er nun den Richtlinien des Kernels entsprach. Nun stimmte das Coding, mit der kleinen Einschränkung, dass der Treiber dermaßen instabil wurde, dass er gleichsam bei allen großen OEMs mit ihren QAs und ihren Testlabors durchfiel.
So kam es, wie es kommen musste. Die OEMs tobten. Eine Krisensitzung folgte der anderen und ein Korrekturpatch dem anderen. Nachdem knapp 2 Monate später die Patches allerdings immer noch nicht in den Kernel implementiert wurden - der brutal schnellen Implementierungspolitik wegen - verlor auch der letzte OEM das Interesse an dem Kernel-Treiber und forderte die Firma auf den alten, stabilen Treiber wieder zu reanimieren. Nun gab es faktisch zwei Treiber: Einen offiziell von der Firma entwickelten und unterstützten, der nur OEMs zugänglich ist und den Privatpersonen nur auf Anfrage erhalten und einen bereinigten Treiber im Kernel, zu dem nur innerhalb eines Jahres über 1400 Bugmeldungen eingeschickt wurden (im Vergleich dazu zu dem alten Treiber kamen in der ganzen Existenzzeit nicht mal 100 Bugs).
Nun wurde es Ende 2008 offenbar auch Novell, dem Arbeitgeber von Herrn Kroah-Hartman, klar, dass der Zustand nicht tragbar ist und wieder schaltete sich der Aufräumer ein. Dabei drohte er mit allerlei Konsequenzen und scheint allerdings der Realität mittlerweile komplett entwachsen zu sein. Denn die Entwicklung des Linux-Treibers hat sich nie wirklich gelohnt. Bei einem Marktanteil von unter einem Prozent sind die Kosten höher als der Nutzen. Wenn davon noch der Groß der Linux-Anwender OEMs sind und diese das Original nutzen, ist sowohl die finanzielle, wie auch die persönliche Motivation bei ziemlich 0 angesiedelt.
Das scheint nun auch dieses Jahr beim Herrn Kroah-Hartman angekommen zu sein, denn sein letzter Anruf war so erstaunlich freundlich, dass wir dachten mit einer anderen Person zu reden als zuvor. Er bat uns mit Zuckerstimme den Treiber ein wenig aufzuräumen und wieder an seine Staging-Feldversuche zu senden. Vorbei scheint die Zeit zu sein, als er sich an den Ifdefs störte, mit denen Änderungen an früheren Kernelversionen markiert waren. Vorbei ist die Zeit, als ihn die gemeinsame Common-Struktur störte. Vorbei der angebliche Bloat, den er bemängelte. Er wollte nur noch, dass wir speziell an eine bestimmte Plattform gemachte Änderungen zurücknehmen. Technisch absolut kein Thema, doch da gibt es ein Problem.
Wer wirklich professionell Treiber für den Kernel entwickelte und mit seinen Produkten Geld verdienen will, kennt diese Sticheleien diverser Alpha-Tiere. Die ständigen Vorschriften, wie etwas zu machen sei und was nicht. Die ständige Angst, dass Änderungen verworfen werden. Denn, sobald eine Funktion nicht in den Kernel aufgenommen wurde, bedeutet es, dass man entweder einen zweiten Treiber mit der Änderung erstellen muss oder einfach damit lebt, dass einem die Funktion X oder Y nicht im eigenen Treiber gestattet wurde.
Hat man sich von dieser Funktionsweise befreit und erkennt, dass man problemlos auch Treiber außerhalb des Kernels ausliefern kann und kein ernsthafter Kunde das einem übel nimmt, muss man nur noch über die Idee von Herrn Kroah-Hartman lachen. Der Zug ist definitiv abgefahren und kein Geringer als der große Aufräumer Kroah-Hartman zeigte uns, dass die Entwicklung eines Treibers außerhalb des Kernels erheblich schneller, entspannter und effektiver sein kann. An dieser Stelle möchte ich mich deshalb bei ihm für seine Impulse bedanken.
Das Problem ist einfach, dass das Modell, alle Treiber mit dem Kernel mitzuliefern veraltet ist, Punkt! Linux BRAUCHT eine halbwegs stabile API/ABI für grundlegende Schnittstellen und besseren Support für Kernel-externe Treiber, da kann GKH soviel herumjammern und herumtrollen, wie er will. Es geht hier nicht nur um ClosedSource-Treiber: durch die zahlreichen andauernden Änderungen macht es keinen Spaß (und teilweise Sinn), Treiber extern vom Kernel zu maintainen (und auch intern macht es großen Aufwand). Davon abgesehen möchte nicht jeder sich dem Codestil und Codekonventionen des Linux-Projekts unterwerfen. Alle Treiber im Kernel aufnehmen zu können ist nur eine Utopie.
Staging ist zwar ein erster Schritt in die richtige Richtung, aber die Treiber sollten dort ruhig dauerhaft verweilen können.
Man könnte ihn ja aus der default Konfiguration ausschließen. So würde wenigstens noch die Möglichkeit bestehen an den Treiber zu kommen. Und ob jetzt die Kernel-Sourcen ein paar kB größer sind, halte ich persönlich für nicht so schlimm. Oder hat das noch andere Auswirkungen?
nach diesen Treibern besteht, wird sich schon jemand
finden der das unter seine Fittiche nimmt.
Wenn nicht, nicht.
Und nun? Alles Blödsinn! Wir rudern mal flott in die andere Richtung...
Doch dann kam das Jahr 2007 oder so und ein gewisser Herr Kroah-Hartman wurde bei uns vorstellig. Jedem Herrn fiel auf, dass die Treiber der Firma Funktionen und Strukturen hatte, die nicht wirklich mit dem Kernel konform waren. Die Firma machte den blödsinnigen Fehler, den Treiber nicht direkt für Linux zu entwickeln, sondern hatte, wie es bei anderen Treibern üblich ist, einen Common- und einen Linux-Code. Der Common-Code stellte die Basis für alle ihre Treiber dar und so konnte sie Problemlos nicht nur ältere Linux-Versionen, sondern auch BSD und andere Systeme unterstützen. Das gefiel aber Herrn Kroah-Hartman nicht und so befahl er, sich im Ton entsprechend vergriffen zu haben, der Firma den Treiber umzuschreiben. Nicht der Stabilität wegen und auch nicht der falschen oder fehlenden Funktionen, sondern nur dem Stil wegen. Der Treiber musste angepasst und bereinigt werden. Im Falle der Zuwiederhandlung drohte er mit der Entfernung.
Da unsere Helden-Firma nun nicht Intel heißt, es sich nicht leisten kann mehrere verschiedene Treiber für den Linux-Kernel zu unterhalten und nicht wirklich gegen das Macho-Gehabe des Herrn Kroah-Hartman ankam, geschah das, was geschehen musste. Der Treiber wurde im Kernel von einem armen Tropf so abgeändert, dass er nun den Richtlinien des Kernels entsprach. Nun stimmte das Coding, mit der kleinen Einschränkung, dass der Treiber dermaßen instabil wurde, dass er gleichsam bei allen großen OEMs mit ihren QAs und ihren Testlabors durchfiel.
So kam es, wie es kommen musste. Die OEMs tobten. Eine Krisensitzung folgte der anderen und ein Korrekturpatch dem anderen. Nachdem knapp 2 Monate später die Patches allerdings immer noch nicht in den Kernel implementiert wurden - der brutal schnellen Implementierungspolitik wegen - verlor auch der letzte OEM das Interesse an dem Kernel-Treiber und forderte die Firma auf den alten, stabilen Treiber wieder zu reanimieren. Nun gab es faktisch zwei Treiber: Einen offiziell von der Firma entwickelten und unterstützten, der nur OEMs zugänglich ist und den Privatpersonen nur auf Anfrage erhalten und einen bereinigten Treiber im Kernel, zu dem nur innerhalb eines Jahres über 1400 Bugmeldungen eingeschickt wurden (im Vergleich dazu zu dem alten Treiber kamen in der ganzen Existenzzeit nicht mal 100 Bugs).
Nun wurde es Ende 2008 offenbar auch Novell, dem Arbeitgeber von Herrn Kroah-Hartman, klar, dass der Zustand nicht tragbar ist und wieder schaltete sich der Aufräumer ein. Dabei drohte er mit allerlei Konsequenzen und scheint allerdings der Realität mittlerweile komplett entwachsen zu sein. Denn die Entwicklung des Linux-Treibers hat sich nie wirklich gelohnt. Bei einem Marktanteil von unter einem Prozent sind die Kosten höher als der Nutzen. Wenn davon noch der Groß der Linux-Anwender OEMs sind und diese das Original nutzen, ist sowohl die finanzielle, wie auch die persönliche Motivation bei ziemlich 0 angesiedelt.
Das scheint nun auch dieses Jahr beim Herrn Kroah-Hartman angekommen zu sein, denn sein letzter Anruf war so erstaunlich freundlich, dass wir dachten mit einer anderen Person zu reden als zuvor. Er bat uns mit Zuckerstimme den Treiber ein wenig aufzuräumen und wieder an seine Staging-Feldversuche zu senden. Vorbei scheint die Zeit zu sein, als er sich an den Ifdefs störte, mit denen Änderungen an früheren Kernelversionen markiert waren. Vorbei ist die Zeit, als ihn die gemeinsame Common-Struktur störte. Vorbei der angebliche Bloat, den er bemängelte. Er wollte nur noch, dass wir speziell an eine bestimmte Plattform gemachte Änderungen zurücknehmen. Technisch absolut kein Thema, doch da gibt es ein Problem.
Wer wirklich professionell Treiber für den Kernel entwickelte und mit seinen Produkten Geld verdienen will, kennt diese Sticheleien diverser Alpha-Tiere. Die ständigen Vorschriften, wie etwas zu machen sei und was nicht. Die ständige Angst, dass Änderungen verworfen werden. Denn, sobald eine Funktion nicht in den Kernel aufgenommen wurde, bedeutet es, dass man entweder einen zweiten Treiber mit der Änderung erstellen muss oder einfach damit lebt, dass einem die Funktion X oder Y nicht im eigenen Treiber gestattet wurde.
Hat man sich von dieser Funktionsweise befreit und erkennt, dass man problemlos auch Treiber außerhalb des Kernels ausliefern kann und kein ernsthafter Kunde das einem übel nimmt, muss man nur noch über die Idee von Herrn Kroah-Hartman lachen. Der Zug ist definitiv abgefahren und kein Geringer als der große Aufräumer Kroah-Hartman zeigte uns, dass die Entwicklung eines Treibers außerhalb des Kernels erheblich schneller, entspannter und effektiver sein kann. An dieser Stelle möchte ich mich deshalb bei ihm für seine Impulse bedanken.
Linux BRAUCHT eine halbwegs stabile API/ABI für grundlegende Schnittstellen und besseren Support für Kernel-externe Treiber, da kann GKH soviel herumjammern und herumtrollen, wie er will. Es geht hier nicht nur um ClosedSource-Treiber: durch die zahlreichen andauernden Änderungen macht es keinen Spaß (und teilweise Sinn), Treiber extern vom Kernel zu maintainen (und auch intern macht es großen Aufwand). Davon abgesehen möchte nicht jeder sich dem Codestil und Codekonventionen des Linux-Projekts unterwerfen. Alle Treiber im Kernel aufnehmen zu können ist nur eine Utopie.
Staging ist zwar ein erster Schritt in die richtige Richtung, aber die Treiber sollten dort ruhig dauerhaft verweilen können.