Wir haben ein Uni Treiber Modell entwickelt und von all unseren Herstellern auch die Erlaubnis erhalten, unsere Treiber zu open sourcen. Dies bedeutet weit mehr
Arbeit, als die Treiber zu schreiben.
Im Gegensatz zu anderen Entwicklern von Treibern arbeiten wir mit den Dokumentationen der Hersteller. Diese stehen anderen Entwicklern oft nicht zur Verfügung. Leider weigern sich einige
Maintainer, fehlende oder falsche Registersettings und Methoden zu ändern oder zu besprechen.
Wir decken viele Anwendungsfälle ab, die über die Einzelinstallation eines Maintainers eines Treibers hinausgehen. Nachdem es aber für einen Baustein nur einen Treiber geben soll, führt das zu Problemen.
Lange Rede – kurzer Sinn:
Im Interesse unserer Kunden arbeiten wir an diesem Problem. Wir können jedoch nicht abschätzen, wie lange es dauern wird, unsere Treiber in den Kernel zu integrieren. Technische Gründe sind nicht die Ursache.
Ein Beispiel:
Unser Treiber für den TDA18212: Im Kernel existiert ein Treiber, der über Reverse Engeneering entstanden ist. Dieser Treiber ist leider nicht vollständig (dies ist kein Vorwurf an den Maintainer, mangels Dokumentation war nicht mehr zu erreichen). Der Maintainer war damit
einverstanden, unseren Treiber zusätzlich im Kernel zu akzeptieren, aber das wurde von dritter Seite mit einem Veto belegt. Usw.
Fazit:
Es gibt leider häufig stärkere politische Interessen als das Interesse daran, das große Ganze zu verbessern.