Уявіть, що існує компанія A, яка випускає новий графічний адаптер. Хто управляє процесом, в результаті якого цей новий графічний адаптер підтримується ядром Linux у майбутньому? Як це відбувається? Мені цікаво, як обробляється підтримка ядра для будь-якого нового обладнання; Компанії Windows розробляють драйвери самостійно, але як Linux отримує конкретну апаратну підтримку?
Відповіді:
Підтримка драйверів працює так само, як і з усім відкритим кодом: хтось вирішує подряпати власний свербіж.
Іноді драйвер постачається компанією, що постачає обладнання, як і в Windows. Intel робить це для своїх мережевих мікросхем, 3ware робить це для своїх RAID-контролерів і т. Д. Ці компанії вирішили, що в їх інтересах надавати драйвер: їх "свербіж" - продавати продукт користувачам Linux, а це означає забезпечити що є водій.
У кращому випадку компанія наполегливо працює над тим, щоб завести свого драйвера у відповідну базу джерел, яка постачається з дистрибутивами Linux. Для більшості драйверів це означає ядро Linux. Для графічних драйверів це означає X.org . Також є CUPS для драйверів принтерів, NUT для драйверів UPS, SANE для драйверів сканерів і т.д. Найбільшим недоліком є те, що компанія більше працює над узгодженням проекту з відкритим кодом, щоб залучати їх драйвера, з тих самих основних причин, що двом окремим групам важко щось узгодити.
Тоді є ті компанії, які вирішують пропонувати лише вихідний код свого драйвера безпосередньо. Зазвичай вам потрібно завантажити вихідний код драйвера з їх веб-сайту, побудувати його у вашій системі та встановити вручну. Такі компанії, як правило, є меншими або спеціалізованими виробниками без достатньої кількості співробітників, які можуть докласти зусиль для координації з відповідним проектом з відкритим кодом, щоб залучити свого водія до джерельної бази цього проекту.
Мало рідкісні компанії надають драйвери лише для бінарних файлів замість вихідного коду. Прикладом можуть бути більш просунуті драйвери 3D від таких компаній, як NVIDIA. Як правило, причиною цього є те, що компанія не хоче передавати інформацію, яку вони вважають власницею. Такі драйвери часто не працюють з такою кількістю дистрибутивів Linux, як у попередніх випадках, тому що компанія, що надає обладнання, не намагається відновити драйвер для відстеження змін API та ABI. Кінцевий користувач або постачальник дистрибутивів Linux може налаштувати драйвер, наданий як вихідний код для відстеження таких змін, тому в попередніх двох випадках драйвер, як правило, може бути змушений працювати з більшою кількістю систем, ніж буде двійковий драйвер.
Коли компанія не надає драйвери Linux, хтось із спільноти просто вирішує це зробити. Існує кілька великих класів обладнання, де це звичайно, як з ДБЖ та принтерів. Це потребує рідкісний користувач, який: a) має обладнання; б) має час; в) володіє майстерністю; г) має схильність витрачати час на розвиток водія. Для популярного обладнання зазвичай це не проблема, оскільки з мільйонами користувачів Linux таких мало хто існує. Ви можете потрапити в проблеми з нечастою технікою.
Щоб зрозуміти це докладно, нещодавно вийшов Raspberry Pi 3 і додав Bluetooth чіп. Тепер це чіп Broadcom BLE і Raspberry Pi ядро не має підтримки для нього і тому bluezбібліотека для Linux не працює. Тепер в ідеалі для цього чіпа BLE слід встановити патч мікропрограмного забезпечення і потрібно буде знову скомпілювати ядро, щоб зробити його доступним для користувача. Це так?