El kernel de Linux se prepara para una limpieza importante en su soporte ARM de 32 bits: una serie de parches enviada por Arnd Bergmann propone retirar plataformas antiguas, archivos de placa heredados y código que ya casi nadie usa en kernels modernos. La primera serie contiene 13 parches y apunta a eliminar 55.679 líneas en 371 archivos, con apenas 115 inserciones.
La medida no debe interpretarse como “Linux abandona ARM”. Al contrario: ARM sigue siendo una arquitectura central en servidores, móviles, placas embebidas, routers, IoT, automoción y nube. Lo que está sobre la mesa es retirar soporte antiguo de plataformas ARM de 32 bits que fueron marcadas como obsoletas en Linux 7.3 y que complican el mantenimiento del kernel moderno.
Idea central: Linux no está eliminando ARM moderno. Está preparando la salida de plataformas ARM muy antiguas, muchas de ellas sin usuarios visibles, sin conversión completa a Device Tree o sin mantenimiento activo en el kernel principal.
1. Qué se propone eliminar exactamente
La serie se titula “ARM: deprecated platform removal” y fue enviada el 8 de septiembre de 2026. Arnd Bergmann explica que en Linux 7.3 marcó varias plataformas y funciones como obsoletas, con la idea de mantenerlas durante el kernel LTS de este año y retirarlas después.
Entre las plataformas afectadas aparecen SA1100, Footbridge, RISCPC, archivos legacy de PXA, Orion/Dove/MV78xx0, OMAP24xx, i.MX31, soporte i.MX sin MMU, LPC18xx, STM32F4/F7/H7, Versatile MPS2, AT91 SAMV7 y Axxia.
| Elemento afectado | Qué significa | Impacto probable |
|---|---|---|
| Plataformas ARM antiguas | Soporte para SoC y placas muy viejas. | Afecta sobre todo a hardware histórico o embebido abandonado. |
| Board files heredados | Código C antiguo que describía hardware directamente en el kernel. | Reduce deuda técnica y favorece Device Tree. |
| Device Tree antiguos | Archivos DTS/DTSI de plataformas sin uso visible. | Menos mantenimiento y pruebas para hardware obsoleto. |
| Drivers huérfanos | Controladores que solo servían para esas plataformas. | Podrían eliminarse después de retirar las plataformas base. |
2. No es una eliminación inmediata: está en revisión
La limpieza todavía debe pasar por el flujo normal del kernel. Bergmann indica que parte del trabajo podría entrar en Linux 7.4, pero que apunta a Linux 7.5 para la mayoría de cambios, con el fin de mantener dependencias simples y dar tiempo a que posibles usuarios activos presenten objeciones antes de que desaparezcan también los drivers asociados.
Lectura correcta: no es una ruptura silenciosa ni una decisión tomada sin aviso. Es una serie de parches pública que busca retirar código obsoleto después de una fase de deprecación y con margen para que usuarios reales defiendan plataformas que todavía dependan del kernel principal.
3. Por qué Linux quiere quitar este código
El motivo principal es mantenimiento. Mantener plataformas viejas no significa solo guardar archivos: implica no romper configuraciones antiguas, revisar dependencias, ajustar Kconfig, conservar drivers específicos, probar caminos raros y evitar que nuevas limpiezas del kernel choquen con código sin usuarios visibles. Phoronix resume que este código antiguo se ha convertido en una carga para desarrolladores upstream y dificulta limpiezas mayores y nuevas funciones.
El propio Bergmann señala que limpiar el código obsoleto resultó más grande de lo esperado: el trabajo ya estaba alrededor de 300 parches, muchos todavía pendientes de dividirse en piezas más pequeñas.
4. Device Tree: la frontera entre ARM moderno y ARM heredado
Una parte del problema histórico de ARM en Linux fue que muchas placas se describían mediante código específico dentro del kernel. Device Tree ayudó a cambiar ese modelo: la documentación oficial del kernel lo define como una descripción de hardware legible por el sistema operativo para que el kernel no tenga que codificar detalles de la máquina directamente.
La documentación también explica que Device Tree permite desacoplar la configuración del hardware del soporte de placas y drivers dentro del kernel, algo especialmente importante en plataformas embebidas.
| Modelo antiguo | Modelo moderno |
|---|---|
| Hardware descrito en archivos C dentro del kernel. | Hardware descrito mediante Device Tree. |
| Cada placa podía requerir código específico. | El kernel puede usar descripciones separadas del hardware. |
| Más deuda técnica y duplicación. | Mejor mantenibilidad y revisión más ordenada. |
5. La cifra: 371 archivos y 55.679 líneas menos
La estadística de la serie es contundente: 371 archivos cambiados, 115 inserciones y 55.679 eliminaciones. Es decir, no estamos ante una corrección menor, sino ante una limpieza masiva de código ARM heredado.
Entre los archivos eliminados aparecen documentación antigua, bindings de Device Tree, archivos DTS/DTSI, configuraciones defconfig, código de plataformas bajo arch/arm/mach-*, partes de arranque comprimido, soporte para placas concretas y referencias en drivers que dependían de esos símbolos Kconfig.
6. Plataformas ARM afectadas
La lista incluye hardware que en muchos casos pertenece a otra era del ecosistema ARM: PDAs, NAS antiguos, placas embebidas de 32 bits, microcontroladores Cortex-M integrados de forma peculiar, plataformas sin Device Tree completo o SoC que ya no cuentan con usuarios activos en mainline.
| Plataforma o familia | Estado propuesto |
|---|---|
| SA1100 | Retiro completo de la plataforma. |
| Footbridge | Eliminación de soporte heredado. |
| RISCPC | Retiro de archivos de plataforma antiguos. |
| PXA legacy | Eliminación de board files heredados. |
| OMAP24xx | Retiro del soporte OMAP2 antiguo. |
| i.MX31 | Eliminación del soporte SoC. |
| STM32F4/F7/H7 | Retiro del soporte MCU dentro de esta serie. |
| Axxia | Eliminación de plataforma completa. |
La propia serie enumera estos objetivos de eliminación en sus 13 parches iniciales.
7. ¿A quién puede afectar?
Para la mayoría de usuarios de escritorio, servidores modernos, Raspberry Pi recientes, placas ARM64, teléfonos actuales y equipos cloud, el impacto será nulo. La limpieza se concentra en plataformas ARM de 32 bits antiguas y específicas.
El usuario potencialmente afectado es alguien que todavía compila kernels mainline recientes para hardware muy antiguo, mantiene una placa industrial heredada, usa un NAS ARM clásico, conserva una PDA o sistema embebido histórico, o depende de una plataforma que nunca migró correctamente a Device Tree.
Importante: si una empresa depende de hardware ARM antiguo, debe revisar si compila kernels mainline modernos o si usa kernels del fabricante. Muchas plataformas obsoletas siguen funcionando con kernels antiguos mantenidos por proveedores, pero eso no equivale a soporte en el kernel principal actual.
8. Por qué retirar código también puede mejorar seguridad
Menos código no significa automáticamente más seguridad, pero sí reduce superficie de mantenimiento. Código antiguo, sin pruebas, sin usuarios visibles y sin mantenedores activos puede acumular errores, bloquear limpiezas internas o impedir que se simplifiquen APIs. En un proyecto del tamaño del kernel Linux, cada plataforma soportada tiene un costo indirecto.
Además, si un driver queda huérfano porque solo servía para una plataforma retirada, puede convertirse en candidato natural para eliminación futura. Phoronix señala que, después de esta primera limpieza, podrían retirarse más drivers huérfanos para lograr ahorro adicional de código.
Punto clave: eliminar código muerto no es destruir historia; es evitar que la historia bloquee el avance técnico del kernel.
9. Linux conserva compatibilidad, pero no infinitamente
Linux tiene fama de soportar hardware durante muchos años, pero esa compatibilidad no es gratuita. Cada línea antigua debe compilar, integrarse, revisarse y no romper cambios modernos. Cuando el hardware ya no tiene usuarios visibles, no tiene mantenedor o impide refactorizaciones importantes, los desarrolladores deben decidir si vale la pena conservarlo.
La discusión no es nueva. El tag de deprecación para Linux 7.3 ya recogía que existía consenso previo para retirar ciertas funciones entre 2025 y 2026, pero que el calendario se movió hacia inicios de 2027 después del kernel LTS correspondiente.
| Razón para conservar | Razón para eliminar |
|---|---|
| Usuarios reales todavía dependen del hardware. | No hay usuarios visibles en kernels mainline actuales. |
| Existe mantenedor activo. | La plataforma bloquea limpiezas y nuevas funciones. |
| Puede migrarse a Device Tree. | Nunca se completó la migración ni hay interés visible. |
10. Qué deben hacer los usuarios de hardware ARM antiguo
Quienes administran hardware ARM muy antiguo deben revisar ahora si su plataforma aparece en la lista. No conviene esperar a que el soporte desaparezca para recién descubrir que una actualización del kernel ya no arranca.
Checklist para usuarios afectados
- Identificar la plataforma: SoC, placa, fabricante, kernel usado y versión.
- Revisar si usa mainline: distinguir entre kernel oficial de Linux y kernel del proveedor.
- Comprobar Device Tree: verificar si la plataforma depende de board files antiguos.
- Evaluar mantenimiento: saber si existe mantenedor activo o comunidad real.
- Participar en LKML: si hay usuarios reales, deben responder antes del retiro definitivo.
- Planificar reemplazo: migrar a hardware moderno cuando el soporte upstream desaparece.
- Congelar kernel si es necesario: usar una versión LTS conocida mientras se planifica transición.
11. Impacto para fabricantes y mantenedores
Para fabricantes, esta limpieza envía una señal clara: no basta subir soporte inicial al kernel y abandonarlo. Las plataformas necesitan mantenimiento, pruebas, conversión a mecanismos modernos y usuarios que respondan cuando el código empieza a romperse.
Para mantenedores, la limpieza libera tiempo. En lugar de conservar indefinidamente código que casi nadie prueba, pueden concentrarse en plataformas activas, ARM64, servidores, sistemas embebidos actuales, drivers modernos y mejoras internas del kernel.
12. ¿Qué pasa con ARM moderno y ARM64?
ARM moderno no está en riesgo por esta serie. El foco está en plataformas antiguas de 32 bits, muchas con soporte histórico arrastrado durante años. ARM64 sigue siendo una arquitectura clave para servidores cloud, portátiles, placas modernas, infraestructura de red, móviles y hardware de alto rendimiento.
La limpieza puede incluso beneficiar a ARM moderno: menos código heredado facilita refactorizaciones, reduce configuraciones no probadas y permite concentrar esfuerzos en hardware actual.
| No afectado directamente | Afectado potencialmente |
|---|---|
| ARM64 moderno. | ARM 32-bit heredado. |
| Servidores cloud ARM recientes. | Placas sin mantenimiento upstream. |
| Raspberry Pi y placas populares actuales. | SoC antiguos sin usuarios en mainline. |
| Dispositivos con soporte Device Tree activo. | Board files C heredados sin conversión. |
13. El mensaje de fondo: Linux está limpiando deuda técnica
El kernel Linux ha crecido durante décadas porque acepta soporte para miles de dispositivos. Esa fortaleza también genera deuda técnica. Cada arquitectura, placa, driver y configuración añade complejidad. Cuando algo ya no se usa, se vuelve difícil justificar su permanencia indefinida.
La eliminación de unas 55.000 líneas no es solo una reducción estética. Es parte de un proceso mayor: quitar plataformas sin futuro upstream, simplificar rutas internas y permitir que el desarrollo avance sin arrastrar dependencias históricas.
Conclusión técnica: la compatibilidad histórica es valiosa, pero no puede convertirse en una obligación eterna cuando no hay usuarios, pruebas ni mantenedores.
14. Preguntas clave
¿Linux va a eliminar soporte para ARM?
No. La propuesta apunta a plataformas ARM antiguas de 32 bits, no al ecosistema ARM moderno ni a ARM64. ARM sigue siendo clave en Linux.
¿Cuántas líneas se eliminarían?
La primera serie muestra 371 archivos modificados, 115 inserciones y 55.679 eliminaciones.
¿Qué versiones del kernel recibirían el cambio?
La idea inicial era retirar código después de marcarlo como obsoleto en Linux 7.3. Parte podría llegar en Linux 7.4, pero Bergmann apunta a Linux 7.5 para la mayoría de cambios por simplicidad de dependencias.
¿Por qué no se mantiene todo para siempre?
Porque cada plataforma soportada exige mantenimiento, pruebas, compatibilidad y revisión. Si no hay usuarios ni mantenedores activos, ese código puede bloquear mejoras y limpiezas del kernel.
¿Qué debo hacer si uso una placa ARM antigua?
Identifica tu SoC y placa, revisa si aparece en la serie, verifica qué kernel usas y participa en la discusión upstream si realmente dependes de mainline. También conviene planificar migración a hardware con soporte activo.
Recomendamos
- Por qué los servidores usan Linux: ventajas para empresas y administradores TI
- Cómo saber si tu Linux necesita una actualización urgente: kernel, paquetes, firmware y vulnerabilidades críticas
- Comandos básicos que debes aprender para administrar tu servidor Linux
- Guía completa de redes en Linux: comandos, diagnóstico, configuración y solución de problemas
- Cómo saber si tu Linux está bien protegido: 30 comprobaciones de seguridad que puedes realizar ahora mismo
- Cómo hacer análisis forense en Linux después de un ciberataque: logs, procesos, conexiones y evidencias
En resumen
El kernel de Linux planea retirar alrededor de 55.000 líneas de código antiguo de ARM, pero la noticia debe leerse con precisión: no es el fin de ARM en Linux, sino una limpieza de plataformas 32-bit obsoletas, board files heredados y soporte que bloquea mantenimiento moderno. La serie inicial propone 13 parches, 371 archivos modificados y 55.679 eliminaciones.
El cambio podría llegar entre Linux 7.4 y Linux 7.5, dando margen para que usuarios reales de estas plataformas presenten objeciones. Para la mayoría de usuarios, no habrá impacto. Para quienes aún dependen de hardware ARM antiguo con kernels mainline recientes, este es el momento de revisar, documentar y participar en la discusión.
Cierre editorial
Linux ha construido su grandeza soportando hardware durante décadas, pero esa compatibilidad también tiene un costo. La limpieza de ARM antiguo muestra una decisión madura: conservar lo útil, retirar lo abandonado y permitir que el kernel siga avanzando. A veces, para que Linux soporte mejor el futuro, necesita dejar de cargar con máquinas que ya casi nadie puede probar.
