Linux-Kernel: Treiber für Mainboard-Chips und -Sensoren verlieren Betreuer
Der Betreuer der für Linux-Kernel-Treiber wichtigen Mainboard-Sensoren kündigt seinen Rückzug aus der Pflege des Codes an. Der Code soll offline genommen werden. Alternativen für Nutzer stehen zurzeit aber nicht bereit.
Der langjährige Betreuer der Hardware-Monitoring-Infrastruktur des Linux-Kernel, Günter Röck, stellt die Pflege seiner Linux-Treiber für einige wichtige Mainboard-Chips und -Sensoren ein. Das geht aus einer Nachricht in den Github-Repositorys von Röck hervor, in denen er ankündigt, den Code offline zu nehmen. Betroffen davon sind die Treiber it87 sowie nct6775, die für eine Vielzahl von kleinen Mainboard-Chips benötigt werden.
In der kurzen Notiz zu dem it87-Treiber schreibt Röck: "Ich konnte die Supportanforderungen für diesen Treiber nicht erfüllen, was zu unangenehmen Erlebnissen und Frustration für alle Beteiligten geführt hat". Die betroffenen Chips dienen üblicherweise zur Kontrolle beziehungsweise zum Zugriff auf verschiedene Mainboard-Sensoren, die etwa über Temperatur oder anliegende Spannung Auskunft geben. Ebenso lässt sich mit Hilfe der Treiber die Lüftersteuerung auswerten und konfigurieren. Benötigt werden die Treiber unter anderem zur Unterstützung einiger moderner Mainboards für AMDs Ryzen- oder Threadripper-CPUs.
Der Nachricht zufolge will Röck die Treiber zum 1. August dieses Jahres von Github entfernen. Interessierte sollten vorher den Code der Treiber klonen und anschließend selbstständig weiter pflegen. Auch der Treiber für Temperatur-Sensoren von AMD-CPUs, k10temp, werde möglicherweise demnächst offline genommen. Das schreibt Röck zumindest in einer Diskussion im Issue-Tracker des Treibers auf Github. Auf seiner persönlichen Webseite verweist Röck noch auf weitere von ihm gepflegte Treiber auf Github, einige der Links führen aber bereits ins Leere, da er diese bereits offline genommen hat.
Keine Mainline-Treiber verfügbar
Aus einer weiteren Diskussion zu dem it87-Treiber lassen sich die Gründe für den Rückzug Röcks aus der Treiberpflege ableiten. So schreibt der Entwickler, dass er diese Arbeit bisher komplett allein durchgeführt habe und dafür auch nicht bezahlt worden sei. Außerdem sei seine verfügbare Zeit beschränkt. Hinzu kommt, dass die Mainboard-Hersteller kaum Informationen zu den kleinen Chips und deren Verwendung bereitstellen. Außerdem müssten die Treiber noch mit einem entsprechenden Board und einer CPU getestet werden, die Röck aber nicht zur Verfügung stehen.
Um Linux-Nutzer dennoch ein einigermaßen zufriedenstellendes Erlebnis bieten zu können, hat Röck die besagten Treiber bisher auf Github Out-of-Tree entwickelt. Das heißt, diese befinden sich nicht im üblichen Mainline-Kernel der Linux-Community, der von Linux-Erfinder Linus Torvalds gepflegt wird. Das ermöglichte Röck zwar schnelle Veränderungen an den Treibern, sorgte aber auch dafür, dass sich der Code von dem im Mainline-Kernel entfernt hat.
Das Problem dieser Trennung sei darüber hinaus auch aus der Situation heraus entstanden, dass sich keine anderen Linux-Entwickler gefunden hätten, die die Treiber für eine eventuelle Integration in den Mainline-Kernel überprüfen. Inzwischen seien die Treiber von Röck soweit von dem Mainline-Code entfernt, dass das Aufräumen und Integrieren wohl gut einen Monat dauern würde, schätzt Röck. Das kann und will der Entwickler offenbar nicht leisten.
Linux-Kernel hat Betreuer-Problem
Seit Jahren diskutiert die Kernel-Community immer wieder Probleme in der Betreuung des Codes. So wird etwa die Zahl der verfügbaren Maintainer prinzipiell als zu gering angesehen. Auch steige die Verantwortung und Arbeitsbelastung der Maintainer kontinuierlich, worauf der Entwickler Wolfram Sang schon vor fast zwei Jahren hinwies. Sang pflegt das für viele weitere Bereiche notwendige I2C-Subsystem ebenfalls in seiner Freizeit und stand eigenen Angaben zufolge bereits mehrfach kurz davor, seine Rolle als I2C-Maintainer aufzugeben.
Es geht um Windows-Consumer-Hardware, wo niemand ein Geschäftsmodell darin sieht, darauf...
Dann sollte man an der Ursache und nicht an den Symptomen arbeiten. Warum lässt sich ein...