Linus Benedict Torvalds es un ingeniero de software finlandés-estadounidense, conocido por iniciar y mantener el desarrollo del kernel Linux,
Hace poco mientras se discutía las soluciones en los procesadores x86 que no admiten la instrucción «cmpxchg8b», Linus Torvalds afirmó que podría ser el momento de hacer que esta instrucción sea obligatoria para que el kernel se ejecute y elimine la compatibilidad con los procesadores i486 que no admiten «cmpxchg8b», en lugar estar de «tratando de emular el funcionamiento» de esta instrucción en procesadores que «ya nadie usa».
Actualmente, casi todas las distribuciones de Linux que continúan admitiendo sistemas x86 de 32 bits han cambiado a compilar el kernel con la opción X86_PAE, que requiere compatibilidad con «cmpxchg8b».
Según Linus, en términos de soporte en el kernel, los procesadores i486 han perdido relevancia, a pesar de que todavía se encuentran en la vida cotidiana. En cierto punto, los procesadores se convierten en piezas de museo, y para ellos es bastante posible arreglárselas con núcleos de «museo».
Cabe mencionar que en dado caso de proceder la eliminación del soporte para el i486 clásic, este no afectará a los procesadores Quark embebidos de Intel, que, aunque pertenecen a la clase i486, incluyen instrucciones adicionales típicas de la generación Pentium, entre ellas «cmpxchg8b».
Ademas de ello se menciona que lo mismo se aplica a los procesadores Vortex86DX. La compatibilidad con los procesadores i386 se eliminó en el kernel hace 10 años.
Tal vez deberíamos morder la bala y decir que solo admitimos x86-32 con ‘cmpxchg8b’ (es decir, Pentium y versiones posteriores).
Deshágase de todos los «emular atómicos de 64 bits con cli/sti, sabiendo que nadie tiene SMP en esas CPU de todos modos», e implemente una configuración genérica x86-32 xchg() usando ese bucle try_cmpxchg64.
Creo que la mayoría (¿todas?) de las distribuciones ya habilitan X86_PAE de todos modos, lo que hace que X86_CMPXCHG64 sea parte del requisito básico.
No es que esté convencido de que la mayoría de las distribuciones incluso hacen desarrollo de 32 bits en estos días.
…
Nos deshicimos de la compatibilidad con i386 en 2012. ¿Quizás es hora de eliminar la compatibilidad con i486 en 2022?
La finalización del soporte de i486 podría ser un hito a considerar, ya que desde no hace mucho diversas distribuciones de Linux, optaron por eliminar el soporte para procesadores de 32 bits, lo cual realmente no repercutió como muchos esperaban. Ya que como tal si, aún existen miles de usuarios que cuentan con ordenadores de bajos recursos, lo que convertía a Linux en una excelente opción para continuar dándoles un uso a estos, en especial en muchas zonas marginadas.
Y aunque se continuara dado el soporte para este tipo de equipos por parte de las principales distribuciones, los requisitos actuales de ellas, hacían que uso fue realmente imposible de realizar. Lo cierto es que aún hay algunas distribuciones que continúan dando el soporte para esta arquitectura y sobre todo que están optimizadas para el uso de equipos de bajos recursos.
Sobre el caso de la finalización del soporte, se menciona que los usuarios que tengan sistemas con procesadores i486 podrán utilizar las versiones LTS del kernel, las cuales se mantendrán por muchos años más.
Por otro lado, tambien vale la pena mencionar que el desarrollador del controlador Linux de código abierto para la GPU Apple AGX utilizada en los chips Apple M1 informó que superó con éxito el 99,3% de las pruebas del conjunto dEQP-GLES2, que verifica el nivel de soporte para la especificación OpenGL ES 2. En el trabajo se utilizaron dos componentes: un controlador DRM para el kernel de Linux, escrito en Rust, y un controlador Mesa escrito en C.
El desarrollo de controladores se complica por el hecho de que Apple M1 usa su propia GPU, diseñada por Apple, ejecuta firmware patentado y usa estructuras de datos compartidas bastante complejas. No hay documentación técnica para la GPU y el desarrollo de controladores independiente utiliza ingeniería inversa de controladores de macOS.
El controlador de código abierto desarrollado para Mesa se probó inicialmente en un entorno macOS hasta que se preparó el controlador DRM (Direct Rendering Manager) requerido para el kernel de Linux, lo que permitió que el controlador desarrollado para Mesa se usara en Linux.
Además del éxito actual al pasar las pruebas dEQP-GLES2, a fines de septiembre, el controlador de Linux para chips Apple M1 alcanzó un nivel adecuado para ejecutar una sesión de GNOME basada en Wayland y ejecutar el juego Neverball y YouTube en el navegador Firefox.
Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.