Wyobraź sobie, że istnieje firma A, która wydaje nową kartę graficzną. Kto zarządza procesem, który powoduje, że ten nowy adapter graficzny będzie obsługiwany przez jądro Linuksa w przyszłości? Jak to działa? Jestem ciekawy, jak obsługiwana jest obsługa jądra dla każdego nowego sprzętu; w systemie Windows firmy opracowują sterowniki samodzielnie, ale w jaki sposób Linux otrzymuje wsparcie dla konkretnego sprzętu?
Odpowiedzi:
Obsługa sterowników działa tak samo, jak w przypadku wszystkich programów typu open source: ktoś decyduje się na podrapanie własnego świądu.
Czasami sterownik jest dostarczany przez firmę dostarczającą sprzęt, tak jak w systemie Windows. Intel robi to dla swoich układów sieciowych, 3ware robi to dla swoich kontrolerów RAID itp. Firmy te zdecydowały, że w najlepszym interesie jest dostarczenie sterownika: ich „itch” polega na sprzedaży produktu użytkownikom systemu Linux, a to oznacza zapewnienie że jest kierowca.
W najlepszym przypadku firma ciężko pracuje, aby uzyskać sterownik do odpowiedniej bazy źródłowej dostarczanej z dystrybucjami Linuksa. W przypadku większości sterowników oznacza to jądro Linux. W przypadku sterowników graficznych oznacza to X.org . Istnieją również CUPS dla sterowników drukarek, NUT dla sterowników UPS, SANE dla sterowników skanerów itp. Oczywistą korzyścią z tego jest to, że dystrybucje Linuksa po zaakceptowaniu sterownika będą obsługiwały sprzęt po wyjęciu z pudełka. Największym minusem jest to, że firma ma więcej pracy, aby koordynować z projektem open source, aby uzyskać sterownik, z tych samych podstawowych powodów, dla których dwie oddzielne grupy mają trudności z koordynacją czegokolwiek.
Są też firmy, które decydują się bezpośrednio oferować kod źródłowy sterownika. Zwykle musisz pobrać kod źródłowy sterownika z jego strony internetowej, zbudować go w systemie i zainstalować ręcznie. Takie firmy to zwykle mniejsi lub wyspecjalizowani producenci bez wystarczającej liczby pracowników, którzy mogą poświęcić wysiłek na koordynację z odpowiednim projektem typu open source, aby wprowadzić swój sterownik do bazy źródłowej tego projektu.
Nieliczne firmy dostarczają sterowniki tylko binarne zamiast kodu źródłowego. Przykładem są bardziej zaawansowane sterowniki 3D takich firm jak NVIDIA. Zazwyczaj powodem tego jest to, że firma nie chce ujawniać informacji, które są jej własnością. Takie sterowniki często nie działają z tyloma dystrybucjami Linuksa, jak w poprzednich przypadkach, ponieważ firma dostarczająca sprzęt nie zadaje sobie trudu przebudowania sterownika w celu śledzenia zmian API i ABI. Użytkownik końcowy lub dostawca dystrybucji systemu Linux może modyfikować sterownik dostarczony jako kod źródłowy, aby śledzić takie zmiany, więc w poprzednich dwóch przypadkach sterownik można zwykle przystosować do pracy z większą liczbą systemów niż sterownik binarny.
Gdy firma nie dostarcza sterowników dla systemu Linux, ktoś ze społeczności po prostu decyduje się to zrobić. Istnieje kilka dużych klas sprzętu, w których jest to powszechne, na przykład w przypadku zasilaczy UPS i drukarek. Rzadki użytkownik, który: a) ma sprzęt; b) ma czas; c) posiada umiejętność; oraz d) ma skłonność do poświęcania czasu na rozwój kierowcy. W przypadku popularnego sprzętu zwykle nie stanowi to problemu, ponieważ przy milionach użytkowników Linuksa istnieje tak niewiele osób. Masz kłopoty z nietypowym sprzętem.
Aby to szczegółowo zrozumieć, niedawno pojawił się Raspberry Pi 3 i dodał układ Bluetooth. Teraz jest to chip Broadcom BLE, a jądro Raspberry Pi nie obsługuje go, więc bluezbiblioteka dla Linuksa nie działa. Teraz idealnie byłoby mieć łatkę oprogramowania dla tego układu BLE i trzeba będzie ponownie skompilować jądro, aby było dostępne dla użytkownika. Czy to prawda?