Представьте, что есть компания A, которая выпускает новый графический адаптер. Кто управляет процессом, в результате которого этот новый графический адаптер будет поддерживаться ядром Linux в будущем? Как это происходит? Мне любопытно, как обрабатывается поддержка ядра для любого нового оборудования; в Windows компании разрабатывают драйверы самостоятельно, но как Linux получает поддержку конкретного оборудования?
Поддержка драйверов работает так же, как и со всеми открытыми исходными кодами: кто-то решает почесать свой собственный зуд.
Иногда драйвер поставляется компанией, поставляющей оборудование, как в Windows. Intel делает это для своих сетевых чипов, 3ware делает это для своих RAID-контроллеров и т. Д. Эти компании решили, что в их интересах предоставить драйвер: их «зуд» заключается в том, чтобы продавать продукт пользователям Linux, а это означает обеспечение что есть водитель.
В лучшем случае компания усердно работает над тем, чтобы установить драйверы в соответствующую исходную базу, поставляемую с дистрибутивами Linux. Для большинства драйверов это означает ядро Linux. Для графических драйверов это означает X.org . Также есть CUPS для драйверов принтеров, NUT для драйверов ИБП, SANE для драйверов сканеров и т. Д. Очевидное преимущество этого состоит в том, что дистрибутивы Linux, созданные после получения драйвера, будут иметь встроенную поддержку оборудования. Самым большим недостатком является то, что компании приходится больше координировать свои действия с проектом с открытым исходным кодом, чтобы внедрить свой драйвер, по тем же базовым причинам двум отдельным группам сложно что-либо координировать.
Тогда есть те компании, которые предпочитают предлагать свой исходный код драйвера только напрямую. Обычно вам нужно скачать исходный код драйвера с их веб-сайта, собрать его в своей системе и установить вручную. Такие компании, как правило, являются небольшими или специализированными производителями без достаточного количества сотрудников, которые могут сэкономить усилия для координации с соответствующим проектом с открытым исходным кодом, чтобы получить драйвер в исходную базу этого проекта.
Редкие компании предоставляют драйверы только для двоичного кода вместо исходного кода. Примером являются более продвинутые 3D-драйверы от таких компаний, как NVIDIA. Обычно причиной этого является то, что компания не хочет выдавать информацию, которая, по их мнению, является частной. Такие драйверы часто не работают с таким количеством дистрибутивов Linux, как в предыдущих случаях, потому что компания, предоставляющая аппаратное обеспечение, не пытается перестроить свой драйвер для отслеживания изменений API и ABI. Конечный пользователь или поставщик дистрибутивов Linux могут настроить драйвер, предоставленный в качестве исходного кода, для отслеживания таких изменений, поэтому в предыдущих двух случаях драйвер обычно можно было настроить для работы с большим количеством систем, чем для бинарного драйвера.
Когда компания не предоставляет драйверы для Linux, кто-то из сообщества просто решает это сделать. Есть несколько больших классов оборудования, где это распространено, например, с ИБП и принтерами. Требуется редкий пользователь, который а) имеет аппаратное обеспечение; б) имеет время; в) обладает навыком; и d) имеет склонность тратить время на развитие водителя. Для популярного оборудования это обычно не проблема, потому что с миллионами пользователей Linux эти немногие существуют. У вас проблемы с необычным оборудованием.
Чтобы разобраться в этом подробнее, недавно вышел Raspberry Pi 3 и добавил чип Bluetooth. Теперь это чип Broadcom BLE, и ядро Raspberry Pi не поддерживает его, поэтому bluezбиблиотека для Linux не работает. Теперь, в идеале, нужно иметь патч прошивки для этого чипа BLE и потребуется заново скомпилировать ядро, чтобы сделать его доступным для пользователя. Это правильно?