Imagine que hay una compañía A que lanza un nuevo adaptador de gráficos. ¿Quién administra el proceso que da como resultado que este nuevo adaptador de gráficos sea compatible con el kernel de Linux en el futuro? ¿Cómo procede eso? Tengo curiosidad por saber cómo se maneja el soporte del kernel para cualquier hardware nuevo; en Windows, las empresas desarrollan sus propios controladores, pero ¿cómo obtiene Linux soporte de hardware específico?
Respuestas:
El soporte de controladores funciona de la misma manera que con todo el código abierto: alguien decide rascarse su propio picor.
A veces, el controlador es suministrado por la compañía que proporciona el hardware, al igual que en Windows. Intel hace esto para sus chips de red, 3ware lo hace para sus controladores RAID, etc. Estas compañías han decidido que les conviene proporcionar el controlador: su "picazón" es vender productos a los usuarios de Linux, y eso significa garantizar Que hay un conductor.
En el mejor de los casos, la compañía trabaja duro para llevar su controlador a la base de origen apropiada que se distribuye con las distribuciones de Linux. Para la mayoría de los controladores, eso significa el kernel de Linux. Para los controladores de gráficos, significa X.org . También hay CUPS para controladores de impresora, NUT para controladores de UPS, SANE para controladores de escáner, etc. El beneficio obvio de hacer esto es que las distribuciones de Linux realizadas después de que el controlador sea aceptado tendrán soporte para el hardware de fábrica. El mayor inconveniente es que es más trabajo para la compañía coordinar con el proyecto de código abierto para obtener su controlador, por las mismas razones básicas que es difícil para dos grupos separados coordinar cualquier cosa.
Luego están aquellas compañías que eligen ofrecer su código fuente de controlador directamente, solo. Por lo general, debe descargar el código fuente del controlador desde su sitio web, compilarlo en su sistema e instalarlo a mano. Dichas compañías son generalmente fabricantes más pequeños o especializados sin suficientes empleados para que puedan ahorrar el esfuerzo de coordinar con el proyecto de código abierto apropiado para llevar a su conductor a la base de origen de ese proyecto.
Algunas pocas compañías proporcionan controladores binarios en lugar de código fuente. Un ejemplo son los controladores 3D más avanzados de compañías como NVIDIA. Por lo general, la razón de esto es que la empresa no quiere regalar información sobre la que se siente propietaria. Dichos controladores a menudo no funcionan con tantas distribuciones de Linux como en los casos anteriores, porque la compañía que proporciona el hardware no se molesta en reconstruir su controlador para rastrear los cambios de API y ABI. Es posible que el usuario final o el proveedor de distribución de Linux modifiquen un controlador proporcionado como código fuente para rastrear dichos cambios, por lo que en los dos casos anteriores, el controlador generalmente puede funcionar con más sistemas que un controlador binario.
Cuando la empresa no proporciona controladores de Linux, alguien de la comunidad simplemente decide hacerlo. Hay algunas clases grandes de hardware donde esto es común, como con UPS e impresoras. Se necesita un usuario raro que a) tenga el hardware; b) tiene el tiempo; c) tiene la habilidad; yd) tiene la inclinación de pasar el tiempo para desarrollar el controlador. Para el hardware popular, esto generalmente no es un problema porque con millones de usuarios de Linux, estas pocas personas existen. Te metes en problemas con hardware poco común.
Para comprender esto en detalle, recientemente salió Raspberry Pi 3 y agregó un chip bluetooth. Ahora que es un chip Broadcom BLE y el núcleo Raspberry Pi no tiene soporte para él, por lo que la bluezbiblioteca para Linux no funciona. Ahora, idealmente, uno debería tener un parche de firmware para ese chip BLE y necesitará compilar el kernel nuevamente para que esté disponible para el usuario. ¿Está bien?