Greg Kroah-Hartman, uno de los encargados del Kernel de Linux recientemente recibió una propuesta en la que dice que es posible que un marco dedicado al desarrollo de controladores en lenguaje Rust sea aceptado en el núcleo.
Aun que de momento no hay nada concreto, para esto, Greg Kroah-Hartman formula dos condiciones: una de ellas es que el marco no se activará por defecto en el caso de su integración, esto, para evitar que uno no necesite Rust para compilar el núcleo; en segundo lugar, que el enfoque propuesto tiene ventajas reales en comparación con las derivadas del uso del lenguaje C.
Es conocido, que Kernel de Linux es el producto de desarrollos en lenguajes C y sobre todo que para Linus Torvalds C esta primero que todo. Por lo que en el desarrollo de los controladores para el sistema todavía reina el uso de C.
Los desarrolladores comprometieron las enormes oportunidades que ofrece en términos de manejo de los recursos de hardware de un sistema informático el uso de Rust.
Y es que cada vez más voces se alzan para llamar el pasaje al lenguaje Rust, uno de los que se supone que reemplaza a C por el control del material.
Y es que en la ultima Cumbre de Seguridad de Linux, los investigadores de seguridad, junto a otros, han señalado una de las mayores deficiencia del lenguaje C son los problemas relacionados con la gestión de la memoria – desbordamientos de búfer, asignaciones, acceso a áreas de memoria inválidas o liberadas, etc.
Según las cifras reportadas por el dúo de investigadores, el resultado del 65% de las vulnerabilidades del kernel de Linux identificadas en los últimos 6 meses. Las cifras de Vulnerabilidades y Exposición Comunes (CVE) son similares: el 15.9% de las 2288 vulnerabilidades que afectaron el Kernel de Linux en 20 años están relacionadas con desbordamientos del búfer.
El equipo de investigación no solo habló sobre los beneficios que ofrece Rust en comparación con C. Aprovechó también la oportunidad para presentar una iniciativa para desarrollar un marco dedicado al desarrollo de controladores de Linux.
En pocas palabras, el esfuerzo consiste trabajar con las API del kernel de Linux. Los desarrollos son para arquitecturas x86, arm / arm64, mips, POWERPC, RISC-V, s390 y SPARC.
Pero el mayor problema radica en que solo Linus Torvalds cree que no hay nada mejor que el lenguaje C para la programación del sistema .
“Debo decir que estoy bastante anticuado en temas como este. La razón por la que comencé Linux y los sistemas operativos en general es que realmente me gusta el hardware. Me gusta explorar el aspecto material.
No lo digo para enfatizar que soy un experto. Lo que quiero decir es que me gusta interactuar con el hardware desde el software. Visto desde este punto de vista, todavía no he visto un lenguaje de programación que solo se aproxime al lenguaje C.
Esta afirmación no es solo porque el C es útil para generar un buen código para manejar el hardware. Además, el uso de C tiene sentido para las personas que piensan como una computadora. Creo que la razón es que las personas que diseñaron el lenguaje C lo hicieron en un momento en que los compiladores tenían que ser simples; en un momento en que el lenguaje tenía que adaptarse a la salida o al resultado esperado.
Entonces, cuando leo el código en lenguaje C, sé cómo se verá el código ensamblador y eso es lo que me interesa “, dijo hace 7 años durante una de sus intervenciones en la conferencia. Centro de tecnología Intel de código abierto.
Anteriormente, ha descartado propuestas similares para introducir C ++ en el círculo de lenguajes dedicados al desarrollo de controladores para Linux. En particular, destacó la posibilidad de hacer que la orientación a objetos sea más limpia con C que con C ++.
La iniciativa de Alex Gaynor y Geoffrey Thomas sigue siendo un gran proyecto en muchos ejes. Por ejemplo, el equipo de investigación enfatiza la necesidad de continuar con el desarrollo de controladores para sistemas de archivos y para tipos de dispositivos específicos.
Entonces tendremos que ver si el contenido puede convencer a los mantenedores de Linux.
Fuente: ubunlog
