Open Source im professionellen Einsatz
Linux-Magazin 10/2014

Zacks Kernel-News

743

Große Menge an Hardwaretreibern erschwert Kernel-Konfiguration und -Build

Suses Jean Delvare warnt auf der Kernel-Mailingliste, die Konfigurationsdateien für den Kernel umfassen mittlerweile mehr als 6000 Zeichen. Außerdem wachse die Anzahl der Treiber und Optionen explosionsartig. Schlimmer noch: Auch das Konfigurationssystem habe Bugs, etwa wenn es Treiber für Hardware, die auf einem System gar nicht vorhanden sei, fest in den Kernel einbaue.

Er schlägt vor, dass jeder neue Hardware-spezifische Treiber von »$hardware || COMPILE_TEST« abhängen solle. So würde klar, welche Geräte den Treiber benötigen. »$hardware« könne dabei von der Top-Level-Architektur wie etwa ARM bis hinunter zu »ARCH_AT91« , »PLATFORM_AT32AP« oder »PICOXCELL_PC3X3« reichen, die Liste ließe sich beliebig verlängern.

Allerdings sei es auch sinnvoll, sie so kurz wie möglich zu halten. Indem man die Abhängigkeiten zwischen einzelner Hardware und »COMPILE_TEST« aufteilt, bliebe der Code in allen Buildtests enthalten. So könnten auch Anwender den Treiber schnell bauen, falls sich die definierte Hardware-Abhängigkeit als zu restriktiv erweise.

Fedora und Suse

Auch Josh Boyer von Fedora gibt zu, sich immer wieder mit der großen Anzahl von Konfigurationsoptionen herumschlagen zu müssen. "Mittlerweile kann ich am Treibernamen erkennen, für welche Architektur der ist. Aber das ist nicht wirklich das, was wir wollen – im Gegenteil." Begeistert schloss er sich Jeans Idee an und zeigte sich froh darüber, dass das Thema endlich einmal auf die Tagesordnung gebracht worden ist.

Dann schaltete sich Greg Kroah-Hartman in die Diskussion ein: Josh riet er, bei Fedora doch einfach standardmäßig »m« (für "als Modul") zu wählen und so alles als Modul bauen zu lassen, was ja ohnehin der empfohlene Weg sei.

Doch weder Suse- noch Fedora-Entwickler konnte das Argument überzeugen, denn auch so ist stets jede Menge exotische Treiber immer mitzubauen. Und die Entscheidung, so Josh, welche Treiber wo überhaupt Sinn ergeben, bleibe bei Distributoren hängen, inklusive des Risikos fehlgeschlagener Builds. Das zöge dann Patches und Break Reports nach sich.

Nicht zeitgemäß

Jean erklärt, die Entscheidung für »m« als Default sei vielleicht in den 90ern praktikabel gewesen, aber heute nicht mehr zeitgemäß. "Damals haben wir vielleicht 3 Prozent nutzloser Treiber mitgeschleppt, weil fast ausschließlich die x86-Architektur vorherrschte. Aber heute würdest du da so viel Overhead mitschleppen, der so vieles verlangsamt, von Depmod bis zu Updates. Wir bei Suse verfahren heute nach dem Schema "no" zu allem, bis sich jemand über fehlende Treiber beschwert."

Dem hielt Greg entgegen, sein Laptop baue einen kompletten Kernel in 20 Minuten, sein Build-Host in der Cloud gar in 5. "Da 100 Module rauszuwerfen bringt sicher einiges, aber ist das nicht ein wenig übertrieben?" Er sehe das Problem auch, doch die Lösung müsse anders funktionieren. Jean hielt dem die 34 Kernel-Flavors entgegen, die Suse anbiete: "Jeder Commit kann da einen Rebuild auslösen, und dann wird jedes Modul, das wir anfassen, automatisch Hunderte Male gebaut."

Auch bei Fedora brauche man eher 30 bis 45 Minuten für einen Build, pflichtet Josh dem bei – und das unnütze Warten sei einfach lästig. Auch Pavel Machek stimmte dem zu: Er entwickele unter anderem Kernel für das N900. Da wäre es schön, wenn der Kernel, wüsste er, es handelt sich um ein N900, schon von vornherein diverse Hardwaregruppen ausschließen und andere einschließen könne. Zum Beispiel gibt es auf dem N900 weder ISA noch PCI.

Hier endete die Diskussion bei Redaktionsschluss. Es blieb unklar, ob Greg überhaupt eine machbare Lösung sieht. Allgemeine Übereinstimmung herrschte jedoch, als er die mangelhafte Dokumentation vieler Treiber ansprach und verlangte, hier müsse eine bessere oder überhaupt einmal eine sinnvolle Qualitätskontrolle her.

Greg Kroah-Hartman will Qualitätskontrolle für Kerneltreiber-Dokumentation.

Linux auf kleinen Systemen

Es entbehrt nicht einer gewissen Ironie, dass Linux-Entwickler mittlerweile damit kämpfen, das Betriebssystem auch auf kleinen Geräten zum Laufen zu bekommen. Die sind nämlich heutzutage deutlich leistungsstärker als zu Beginn der Linux-Ära vor gut 20 Jahren.

Andi Kleen beispielsweise weist darauf hin, wie problematisch die heutige Größe des Netzwerkstacks auf einem System wie Intels Quark SoC bereits sei: "Das hat nur zwischen 2 und 4 MByte RAM, und wer da IPv4 anschaltet, belegt gleich mal 400 KByte nur damit – das verbietet sich von selbst."

Diesen Artikel als PDF kaufen

Express-Kauf als PDF

Umfang: 2 Heftseiten

Preis € 0,99
(inkl. 19% MwSt.)

Linux-Magazin kaufen

Einzelne Ausgabe
 
Abonnements
 
TABLET & SMARTPHONE APPS
Bald erhältlich
Get it on Google Play

Deutschland

comments powered by Disqus

Ausgabe 11/2017

Digitale Ausgabe: Preis € 6,40
(inkl. 19% MwSt.)

Stellenmarkt

Artikelserien und interessante Workshops aus dem Magazin können Sie hier als Bundle erwerben.