Stellen Sie sich vor, es gibt eine Firma A, die eine neue Grafikkarte herausbringt. Wer verwaltet den Prozess, der dazu führt, dass dieser neue Grafikadapter zukünftig vom Linux-Kernel unterstützt wird? Wie läuft das ab? Ich bin gespannt, wie die Kernelunterstützung für neue Hardware gehandhabt wird. Unter Windows entwickeln Unternehmen Treiber selbst, aber wie erhält Linux spezifische Hardware-Unterstützung?
Die Treiberunterstützung funktioniert genauso wie bei Open Source: Jemand beschließt, seinen eigenen Juckreiz zu kratzen.
Manchmal wird der Treiber von der Firma geliefert, die die Hardware bereitstellt, genau wie unter Windows. Intel übernimmt dies für seine Netzwerkchips, 3ware für seine RAID-Controller usw. Diese Unternehmen haben entschieden, dass es in ihrem besten Interesse ist, den Treiber bereitzustellen: Ihr "Juckreiz" ist es, Produkte an Linux-Benutzer zu verkaufen, und das bedeutet, sicherzustellen dass es einen Fahrer gibt.
Im besten Fall arbeitet das Unternehmen hart daran, seinen Treiber in die entsprechende Quellbasis zu bringen, die mit Linux-Distributionen geliefert wird. Für die meisten Treiber bedeutet das den Linux-Kernel. Für Grafiktreiber bedeutet dies X.org . Es gibt auch CUPS für Druckertreiber, NUT für USV-Treiber, SANE für Scannertreiber usw. Der offensichtliche Vorteil dabei ist, dass Linux-Distributionen, die nach der Akzeptanz des Treibers erstellt wurden, die sofort einsatzbereite Hardware unterstützen. Der größte Nachteil ist, dass es für das Unternehmen mehr Arbeit ist, sich mit dem Open-Source-Projekt abzustimmen, um den Fahrer für sich zu gewinnen. Aus denselben grundlegenden Gründen ist es für zwei separate Gruppen schwierig, etwas zu koordinieren.
Es gibt auch Unternehmen, die ihren Treiber-Quellcode nur direkt anbieten. Normalerweise müssen Sie den Treiber-Quellcode von der Website herunterladen, auf Ihrem System erstellen und manuell installieren. Solche Unternehmen sind in der Regel kleinere Hersteller oder Spezialhersteller, denen nicht genügend Mitarbeiter zur Verfügung stehen, um sich mit dem entsprechenden Open-Source-Projekt abzustimmen und ihren Treiber in die Quellbasis des Projekts einzubinden.
Nur wenige Unternehmen bieten Binärtreiber anstelle von Quellcode an. Ein Beispiel sind die fortgeschritteneren 3D-Treiber von Unternehmen wie NVIDIA. In der Regel liegt der Grund dafür darin, dass das Unternehmen keine Informationen preisgeben möchte, über die es sich als geschützt fühlt. Solche Treiber funktionieren häufig nicht mit so vielen Linux-Distributionen wie in den vorherigen Fällen, da das Unternehmen, das die Hardware bereitstellt, sich nicht die Mühe macht, den Treiber neu zu erstellen, um API- und ABI-Änderungen nachzuverfolgen. Es ist für den Endbenutzer oder den Linux-Distributor möglich, einen als Quellcode bereitgestellten Treiber zu optimieren, um solche Änderungen nachzuverfolgen. In den beiden vorherigen Fällen kann der Treiber normalerweise für mehr Systeme verwendet werden als ein Binärtreiber.
Wenn das Unternehmen keine Linux-Treiber zur Verfügung stellt, entscheidet sich einfach jemand in der Community dafür. Es gibt einige große Hardwareklassen, bei denen dies üblich ist, wie bei USVs und Druckern. Es braucht einen seltenen Benutzer, der a) die Hardware hat; b) hat die Zeit; c) die Fähigkeit hat; und d) die Neigung hat, die Zeit für die Entwicklung des Fahrers zu verwenden. Bei gängiger Hardware ist dies normalerweise kein Problem, da es bei Millionen von Linux-Benutzern diese wenigen Personen gibt. Sie bekommen Probleme mit ungewöhnlicher Hardware.
Um dies im Detail zu verstehen, kam kürzlich Raspberry Pi 3 heraus und fügte einen Bluetooth-Chip hinzu. Das ist ein Broadcom BLE-Chip und der Raspberry Pi-Kernel unterstützt ihn nicht. Daher funktioniert die bluezBibliothek für Linux nicht. Jetzt sollte man im Idealfall einen Firmware-Patch für diesen BLE-Chip haben und den Kernel erneut kompilieren müssen, um ihn dem Benutzer zur Verfügung zu stellen. Ist das richtig?