Ya fue publicada la quinta versión de los parches para el soporte de controladores Rust en Linux

Hace poco Miguel Ojeda, autor del proyecto Rust-for-Linux dio a conocer la quinta propuesta a los desarrolladores del kernel de Linux de la opción para los componentes de desarrollo de controladores de dispositivos Rust para que la consideren.

Para quienes aún desconocen de esta serie de propuestas que se han venido publicando ya durante varios meses, deben saber que la idea detrás de ello es debido a que actualmente el soporte de Rust se considera experimental, pero ya está incluido en la rama linux-next y es lo suficientemente maduro como para comenzar a trabajar en la creación de capas de abstracción sobre los subsistemas del kernel, así como en la escritura de controladores y módulos.

Actualmente, el encargo del desarrollo de Miguel Ojeda está financiado por Google y el ISRG (Internet Security Research Group), que es el fundador del proyecto Let’s Encrypt y promueve HTTPS y el desarrollo de tecnologías para aumentar la seguridad de Internet.

Es importante mencionar que los cambios propuestos hacen posible el uso de Rust como segundo lenguaje para desarrollar controladores y módulos del kernel. El soporte de Rust se presenta como una opción que no está habilitada de forma predeterminada y no da como resultado la inclusión de Rust entre las dependencias de compilación requeridas para el kernel.

El uso de Rust para desarrollar controladores permitirá crear controladores mejores y más seguros con un esfuerzo mínimo, sin problemas como acceder a un área de memoria después de liberarla, desreferenciar punteros nulos y desbordamientos de búfer.

La seguridad de la memoria se proporciona en Rust en tiempo de compilación mediante la verificación de referencias, el seguimiento de la propiedad del objeto y la vida útil del objeto (alcance), así como mediante la evaluación de la corrección del acceso a la memoria durante la ejecución del código. Rust también brinda protección contra desbordamientos de enteros, requiere que las variables se inicialicen antes de su uso, maneja mejor los errores en la biblioteca estándar, aplica el concepto de referencias y variables inmutables de forma predeterminada y ofrece tipado estático fuerte para minimizar los errores lógicos.

Principales novedades en la quinta propuesta

En la nueva versión de los parches, se continuó con la eliminación de los comentarios realizados durante la discusión de la primera, segunda, tercera y cuarta edición de los parches.

En la parte de los cambios y mejoras que se han realizado podremos encontrar que la validación de componentes para la compatibilidad con Rust se ha agregado al sistema de integración continua basado en el bot 0DAY/LKP compatible con Intel y se han comenzado a publicar los informes de prueba.

Ademas de ello se destaca que se está preparando la integración del soporte de Rust en el sistema de pruebas automatizado KernelCI, ademas de que las pruebas basadas en GitHub CI se cambiaron al uso de contenedores.

Tambien se destaca que se agregó la capacidad de poder definir los parámetros adicionales al registrar dispositivos, asi como tambien que se ha rediseñado el script is_rust_module.sh y que se agregó el soporte para primitivas de sincronización estáticas (variables compartidas globales) basadas en la implementación «CONFIG_CONSTRUCTORS».

De los demás cambios que se destacan en esta nueva propuesta de los controladores:

• Los módulos de Rust Core se ahorran la necesidad de definir los atributos: «#![no_std]» y «#![feature(…)]».
• Se agregó el soporte para objetivos de compilación únicos (.o, .s, .ll e .i).
• Ahora las pautas de código definen reglas para delimitar comentarios («//») y documentar código («///»).
• Gestión de bloqueo simplificada: Guard y GuardMut se combinan en un tipo parametrizado.
• Se ha agregado la abstracción «RwSemaphore», que actúa como un envoltorio sobre la estructura C rw_semaphore.
• Para usar mmap, se agregaron un nuevo módulo mm y una abstracción VMA (enlace sobre la estructura vm_area_struct).
• El controlador GPIO PL061 se cambió para usar la macro «dev_*!».
• Limpieza general del código.

Finalmente si estás interesado en poder conocer más al respecto sobre esta nueva propuesta, puedes consultar los detalles en el siguiente enlace.