El kernel de Linux estudia retirar el controlador del sistema de archivos HPFS después de casi cuatro décadas instalado en su árbol de código. Un parche publicado en la lista de correo de los desarrolladores propone eliminar sus 6.969 líneas por falta de mantenimiento y por una vulnerabilidad reciente. Os contamos qué plantea exactamente esta propuesta y qué supone para quien aún dependa de sistemas heredados.
HPFS (High Performance File System), el sistema de archivos que IBM y Microsoft diseñaron en su día para OS/2, podría decir adiós al kernel de Linux. La propuesta circula en la lista de correo de los desarrolladores del núcleo, donde se ha presentado el parche que elimina su controlador. El objetivo es retirar por completo el código que gestiona este formato, huérfano desde hace años y con limitaciones técnicas capaces de comprometer la estabilidad del sistema.
Qué plantea exactamente el parche que elimina HPFS
El parche en debate propone suprimir íntegramente el controlador de HPFS, lo que se traduce en la eliminación de 6.969 líneas de código que hasta ahora permitían a Linux leer y escribir en este formato heredado. No se trata de un ajuste menor, sino de retirar el componente del árbol de fuentes principal, cambiando así cómo el núcleo trata los volúmenes de OS/2.
Todavía no hay luz verde definitiva: el parche sigue en fase de revisión y su integración se baraja para la futura rama Linux 7.5, aunque esa fecha no es una certeza cerrada. Mientras los mantenedores no den su visto bueno y se cierre el periodo de comentarios, HPFS sigue presente en las versiones actuales del kernel.
Varios motivos técnicos respaldan la retirada. El código lleva tiempo huérfano, sin un mantenedor que se responsabilice de su evolución o de corregir errores, y su base de usuarios activos es prácticamente inexistente. Mantenerlo, a estas alturas, resulta un esfuerzo que no beneficia a nadie dentro del equipo principal del kernel.
A esas carencias se suma algo más grave: el controlador no funciona correctamente ni en configuraciones SMP (multiprocesamiento simétrico) ni en entornos PREEMPT, dos piezas habituales en cualquier instalación de Linux moderna. Y hay una vulnerabilidad reciente capaz de provocar un kernel panic, el fallo que obliga a detener el sistema por completo para evitar daños mayores. Con esos antecedentes, conservar el componente añade un riesgo que pocos dentro del proyecto están dispuestos a asumir.
A quién afecta esta retirada en Linux
Para el usuario doméstico de Linux el impacto será prácticamente nulo: HPFS pertenece a un sistema operativo de otra época. La historia cambia para quienes administran infraestructuras críticas, entornos industriales o pipelines de datos que todavía dependan de leer particiones HPFS de forma nativa; a ellos la retirada sí les afecta de manera directa.
Antes de dar el salto a futuras versiones del kernel merece la pena revisar estos entornos y comprobar si realmente hay dependencias activas de este sistema de archivos. Los administradores deberían auditar servidores y estaciones de trabajo para verificar si se montan particiones HPFS y, si es el caso, planificar la migración a un formato soportado. De no hacerlo a tiempo, el acceso a los datos almacenados en esos volúmenes antiguos podría complicarse.
Alternativas para seguir accediendo a datos en HPFS
Si el parche acaba integrándose y el controlador desaparece en una futura versión del kernel, quienes aún necesiten leer datos en HPFS tendrán que buscar otra vía. La más inmediata pasa por mantener una versión anterior del kernel donde el controlador siga activo, lo que permite seguir leyendo las particiones sin tocar los datos, aunque a costa de renunciar a las nuevas características y parches de seguridad del núcleo.
Otra posibilidad es recurrir a herramientas externas o entornos virtuales que conserven el soporte nativo para OS/2. A largo plazo, la opción más práctica suele ser migrar los datos desde las imágenes o particiones HPFS a un sistema de archivos moderno, como ext4 o Btrfs: se copian los archivos mientras el formato original todavía puede leerse y después se restauran en el nuevo volumen, sin quedar atados a código obsoleto.
Retirar controladores antiguos como el de HPFS tiene un efecto directo en la higiene del código del kernel: cada línea que desaparece reduce la superficie de mantenimiento y, sobre todo, la de auditoría. En un proyecto donde la seguridad pesa cada vez más, tener menos código que revisar deja a los desarrolladores centrarse en los componentes que sí están activos.
Ese detalle gana peso ahora que hay agentes de inteligencia artificial revisando el árbol de fuentes en busca de vulnerabilidades o ineficiencias. Un código huérfano, con fallos conocidos y sin mantenimiento, es ruido que complica esas auditorías automatizadas. El caso de HPFS encaja en esa lógica de limpieza: al retirar sus 6.969 líneas, el kernel no solo se quita de encima un formato obsoleto, también afina sus propios procesos de revisión y reduce los vectores de ataque potenciales.
De OS/2 al kernel de Linux: por qué HPFS llegó aquí
Entender por qué HPFS ha aguantado tanto tiempo requiere mirar atrás. Este sistema de archivos nació de la colaboración entre IBM y Microsoft a finales de los años ochenta, pensado para superar las limitaciones de FAT y sostener el sistema operativo OS/2. Su soporte en Linux habría respondido a la necesidad de leer particiones de otros sistemas operativos en configuraciones de arranque dual, una práctica habitual en los primeros años de adopción del núcleo.
Casi cuarenta años después, HPFS sigue en el árbol del kernel como un vestigio de aquella etapa de la computación personal. La consolidación de formatos como NTFS o ext4 como estándares habría dejado su uso en un segundo plano, y su permanencia hasta hoy se explica más por la inercia del código abierto, donde retirar un componente exige justificar técnicamente su eliminación, que por una necesidad real de mantenerlo. Ese proceso, por fin, parece estar llegando a su fin.