Hace pocas semanas se había dado a conocer la noticia de sobre algunas implementaciones que se realizaron en la rama linux-next, en el cual se incluye un conjunto inicial de componentes para desarrollar controladores de dispositivos en el lenguaje Rust.
Dicha documentación fue publicada por separado sobre el uso de Rust en el kernel de Linux y un ejemplo de un módulo de kernel con un controlador de dispositivo de caracteres en el lenguaje Rust. El código fue agregado por Stephen Rothwell, mantenedor de la rama.
Después de ello Linus Torvalds pasó revisando la implementación de parches de posibilidades para establecer controladores de lenguaje Rust en el kernel de Linux y expresó algunas críticas.
Las mayores quejas fueron causadas por el potencial de escape «run-time failure panicen» en situaciones erróneas, por ejemplo, en una situación de memoria insuficiente, cuando las operaciones de asignación de memoria dinámica, incluidas las del kernel, pueden fallar.
Torvalds declaró que tal enfoque en el kernel es fundamentalmente inaceptable, y si no comprende este punto, puede rechazar completamente cualquier código que intente usar tal enfoque. Por otro lado, el desarrollador del parche estuvo de acuerdo con el problema y lo consideró solucionable.
Otro problema han sido los intentos de utilizar tipos de coma flotante o de 128 bits, que no son válidos para entornos como el kernel de Linux.
Es posible que no entienda las ramificaciones de cuándo puede suceder, por lo que tal vez
sea un problema menor de lo que creo que es, pero fundamentalmente
creo que si alguna asignación de Rust puede causar pánico, esto es simplemente
_ fundamentalmente_ no aceptable.Las fallas de asignación en un controlador o código no central, y eso es, por
definición, todo el código Rust nuevo, nunca NUNCA pueden causar
pánico de manera válida . Lo mismo ocurre con «oh, en algún caso no probé el uso de
enteros de 128 bits o de punto flotante».Entonces, si el compilador de Rust causa asignaciones ocultas que no se pueden
detectar y devolver como errores, entonces creo seriamente que todo este
enfoque debe ser completamente NAK’ed, y la infraestructura de Rust,
ya sea a nivel del compilador o en los envoltorios del kernel, necesita más
trabajo.
Esto resultó ser un problema más serio, ya que en este momento la biblioteca central de Rust es indivisible y representa una gran mancha; no hay forma de solicitar solo algunas de las características, lo que evita el uso de una u otra funcionalidad problemática.
La solución al problema puede requerir cambios en el compilador y la biblioteca de rust, aunque el equipo aún no tiene una estrategia sobre cómo implementar la modularidad de las bibliotecas de idiomas.
Además, Torvalds señaló que el controlador de ejemplo proporcionado es inútil y aconsejó adjuntar como ejemplo algún controlador que resuelva uno de los problemas reales.
Ante esto Google anunció su participación en una iniciativa para promover el soporte de Rust en el kernel de Linux y brindó aspectos técnicos de la viabilidad de implementar Rust para combatir los problemas que surgen de errores en el trabajo con la memoria.
Google cree que Rust está listo para unirse a C como lenguaje para desarrollar componentes del kernel de Linux. El artículo también proporciona ejemplos del uso del lenguaje Rust para desarrollar controladores de kernel, en el contexto de su uso en la plataforma Android (Rust es reconocido como un lenguaje oficialmente soportado para el desarrollo de Android).
Cabe señalar que Google ha preparado un prototipo inicial de un controlador escrito en Rust para el mecanismo de comunicación entre procesos de Binder, que permitirá una comparación detallada del rendimiento y la seguridad de las implementaciones de Binder en C y Rust.
En su forma actual, el trabajo aún no se ha completado, pero para casi todas las abstracciones básicas de la funcionalidad del kernel requeridas para que Binder funcione, se han preparado capas para usar estas abstracciones en el código Rust.
Finalmente si quieres conocer más al respecto, puedes consultar los detalles en el siguiente enlace.
Todas sus críticas son válidas, dado que Rust es un lenguaje nuevo que trabaja con un paradigma diferente al de C es comprensible la preocupación ante cualquier detalle en las librerías o en el propio compilador donde si bien el código sea válido haga quebrar el kernel tal y como está implementado y construido. Por eso las sugerencias como el poder modularizar la biblioteca para llamar y mantener activas sólo aquellas funciones necesarias para el programa (o en este caso para cualquier controlador) trabaje correctamente. Tampoco lo que pide es descabellado, que le traigan un prototipo real de controlador que haga bien un trabajo sobre un problema actual (o que al menos haga el mismo trabajo de uno existente en el kernel y funcione sin entrar en pánico).
De vez en cuando vuelvo a leer artículos de Linux Adictos pero tardo muy poco en desesperarme al ver que a pesar de tener muy buenos contenidos se destroza el resultado final con una ortografía espantosa.
¿Será tan difícil la ortografía y la gramática?
¡Una lástima!
¡Ánimo!