Una discusión en la lista de correo del kernel de Linux este fin de semana festivo que está viendo opiniones polarizadas sobre el asunto está en torno a una nueva serie de parches que proponen soporte de apagado basado en prioridades para controladores/hardware.
Oleksij Rempel, de la consultora Pengutronix embedded Linux, envió el viernes una serie de parches para añadir soporte de apagado basado en prioridades. El objetivo es proporcionar la capacidad dentro del núcleo principal de Linux para priorizar el apagado de dispositivos específicos en primer lugar, como en los casos de pérdida de energía. Este soporte de apagado basado en prioridades parece motivado por la industria automotriz de Linux, donde una solución de software como ésta es "crucial en escenarios como la pérdida de energía, donde puede ocurrir daño al hardware si no se maneja adecuadamente."
Puede leer también | Cómo es la sostenibilidad y mantenimiento del Kernel de Linux
Con la serie de parches este soporte de apagado de dispositivos priorizado se centró en apagar correctamente los dispositivos críticos durante eventos de apagado inesperados / inmediatos como caídas de energía / voltaje o apagado completo. Como parte de la serie de parches, también se ha dado mayor prioridad a los dispositivos de almacenamiento (e)MMC durante la fase de apagado para ayudar a garantizar la integridad/corrupción de los datos.
Aunque a un alto nivel este soporte de apagado basado en prioridades parece estar bien si hay una buena razón para que un dispositivo/driver quiera preparar un dispositivo para apagarse primero, como por ejemplo si esto evitara la pérdida de datos u otra ventaja significativa. Pero en la práctica es más difícil de llevar a cabo cuando podría haber varios controladores reclamando "prioridad" en el proceso de apagado y otros obstáculos para garantizar que se trata de un diseño sólido y que resolverá adecuadamente un problema real.
Puede leer también | Linus Torvalds y su post para presentar el kernel de Linux 6.5
Greg Kroah-Hartman se apresuró a cuestionar este apoyo al cierre basado en la prioridad. Greg comentó inicialmente:
"¡Oh, qué divertido, ahora tendremos controladores y subsistemas peleándose por su prioridad, con cada uno insistiendo en que son los más importantes!
De todos modos, esto es propicio para problemas y cuestiones a largo plazo, ¿qué tiene de especial este hardware que no puede simplemente apagarse en el orden existente que tiene que ser "primero" sobre todos los demás? ¿Qué es exactamente lo que impide esto y qué dispositivos requieren esto?
Y lo más importante, ¿qué ha cambiado en los últimos más de 20 años para requerir de repente esta nueva funcionalidad y cómo lo maneja cualquier otro sistema operativo?".
Puede leer también | Disponible Arch Linux 2023.08.01 con Kernel Linux 6.4 y Archinstall 2.6
Ha habido muchas respuestas desde entonces en ambos lados y si el núcleo principal de Linux debe tener tal funcionalidad para solucionar eficazmente los diseños de hardware cuestionables. Resulta que algunas versiones del kernel Linux fuera de línea para la industria del automóvil ya cuentan con este soporte de apagado prioritario. La necesidad fue resumida por Oleksij Rempel como:
"Evita daños en el hardware. En un trabajo típico de bajo voltaje en automoción es normalmente posible reproducir X cantidad de eMMCs o NANDs dañadas en Y cantidad de ciclos de bajo voltaje (no tengo números exactos ahora mismo). Incluso si los números no son tan altos en las pruebas de trabajo (a veces algo así como un dispositivo dañado en un mes de pruebas), las devoluciones de campo son lo suficientemente importantes como para preocuparse por la solución de software para este problema.
Puede leer también | El Kernel de Linux obtiene más infraestructura para Rust
El mismo problema se observó no sólo en los dispositivos de automoción, sino también en los industriales o agrícolas. En otras palabras, es lo suficientemente importante como para traer algún tipo de solución a la línea principal".
Más tarde, Greg bromeó: "¿Así que el hardware intenta apoyarse en el software para evitar la destrucción de ese mismo hardware? Seguro que los diseñadores de hardware no están tan locos, ¿verdad?
También se planteó por qué dicha funcionalidad no podía implementarse en el espacio de usuario, entre otras ideas. Aquellos interesados en una lectura divertida del fin de semana de la lista de correo del kernel de Linux pueden ver este hilo de la lista de correo del kernel. Hasta el momento hay opiniones muy diferentes sobre este enfoque y queda por ver en esta etapa si se puede idear una solución adecuada que sea aceptable para la línea principal y al mismo tiempo se ajuste a las necesidades de la automoción y más ampliamente al espacio integrado/industrial.
