Microsoft anuncia la liberación como código abierto de ThreadX (Azure RTOS)

• Microsoft liberó como código abierto ThreadX, el sistema operativo en tiempo real que obtuvo tras la adquisición de Express Logic.
• ThreadX RTOS y el paquete de desarrollo Azure RTOS que lo incluye fueron donados a la Eclipse Foundation, pasarán a conocerse como Eclipse ThreadX y podrán usarse bajo licencia MIT.
• Existen varios sistemas operativos en tiempo real (RTOS), pero ThreadX ya se usa en más de 1,200 millones de dispositivos y cumple un papel clave en varios equipos, incluido Raspberry Pi.

Relación entre Raspberry Pi y ThreadX

• ThreadX se usa para ejecutar el motor de administración integrado en chips de Intel y el firmware de Raspberry Pi.
• En Raspberry Pi 1, 2 y 3 se llama bootcode.bin, y en Pi 4 y 400 start*.elf; está incluido en GitHub y Debian, pero es un "blob" propietario cuyo código fuente no ha sido publicado.
• Se ejecuta en la GPU VideoCore de Raspberry Pi, y los núcleos Arm funcionan como dispositivos esclavos dependientes de la GPU.

El significado de la adquisición de ThreadX por parte de Microsoft y su liberación como código abierto

• En 2019, cuando ThreadX cumplió 21 años, Microsoft adquirió Express Logic y lo renombró como Azure RTOS.
• Esta adquisición parece haber sido una respuesta a que AWS tomó el control de FreeRTOS; el desarrollador original, William Lamie, fundó una nueva empresa y ahora comercializa PX5OS, un RTOS de "quinta generación" con hilos compatibles con POSIX.
• ThreadX es un producto probado, y algunas versiones recibieron certificación de seguridad funcional de TÜV, lo que resulta atractivo para ciertos clientes.

Opinión de GN⁺

• El punto más importante de este artículo es que Microsoft liberó como código abierto ThreadX RTOS, un cambio relevante que puede ofrecer más oportunidades a la comunidad de desarrolladores e impulsar la innovación tecnológica.
• La liberación como código abierto abre la posibilidad de que la pila de software de dispositivos como Raspberry Pi llegue a ser completamente de código abierto, lo que podría convertirlos en una opción más atractiva para muchas personas.
• Este cambio es una noticia interesante tanto para entusiastas de la tecnología como para profesionales, y se espera que tenga un impacto positivo en el crecimiento y la innovación del ecosistema de código abierto.

[GN⁺]

Opiniones de Hacker News

• "Azure RTOS" es algo que Microsoft compró apresuradamente después de que Amazon adquiriera FreeRTOS. Bill Lamie inició PX5 y se llevó a la mayoría del talento para trabajar en un nuevo RTOS embebido ligero. Si Microsoft toma esta medida, podría significar que Azure RTOS y los nodos IoT están saliendo de su hoja de ruta. ThreadX tiene un ecosistema mucho más grande que FreeRTOS y funciona también en muchas cosas aparte de Raspberry Pi. Renesas lo ofrecía gratis si comprabas sus SoC.
• La certificación de seguridad es especialmente interesante. Desarrollar "software seguro" requiere muchísimo trabajo. Tener un RTOS de código abierto y además con certificación de seguridad es algo bastante bueno. Para mantener esa certificación, habrá que invertir en algún lado. Entender los estándares de seguridad, establecer el proceso de desarrollo correcto y mantenerlo conforme el software cambia no es tan simple como solo escribir y ejecutar código. No es el tipo de desarrollo de software que se pueda hacer como hobby. Espero que Microsoft financie ese esfuerzo de desarrollo. FreeRTOS no tiene certificación de seguridad, pero SAFERTOS, una implementación comercial con la misma API, sí la tiene.
• Cuando usé ThreadX, me gustó mucho. Llamarlo un "sistema operativo" es una forma bastante generosa de decirlo, ya que consiste en funciones que proporcionan cosas como rutinas de servicio de interrupción, creación de hilos y gestión de asignación de memoria. ThreadX era muy ligero y funcionaba muy bien para sacar el trabajo adelante. Llamabas funciones como tx_thread_create, tx_malloc, etc., y usabas colas, semáforos, mutexes y demás. Da gusto ver que ThreadX sigue vivo. Como tenía que manejar bucles de control en tiempo real de energía/ventiladores/temperatura, necesitaba poder controlar cuándo ocurrían ciertas tareas y, después de detectar un problema, responder emitiendo un comando dentro de un tiempo determinado para reaccionar o mantener el sistema seguro.
• Para quienes se preguntan por qué Azure tiene un RTOS, Microsoft adquirió Express Logic y su RTOS ThreadX en 2019. ThreadX se usa en microcontroladores con recursos muy limitados. La marca Azure no parece significar gran cosa, más allá de que los dispositivos IoT se comuniquen con la nube.
• Solo la versión actual está en GitHub y no se ven rastros de la versión para VideoCore. Queda la esperanza de que Raspberry Pi Foundation pueda conseguir permiso para publicar el código fuente de su propia versión.
• El código está bien, pero creo que hay varias formas de hacerlo más portable y más amigable para el programador. Eso aplica especialmente a las partes de código ensamblador porteadas. Es difícil modificar los índices de las estructuras de datos, así que cambiar estructuras no es fácil. Si las estructuras en C y los índices en el ensamblador no están sincronizados, el sistema puede fallar. Si los índices del ensamblador se convirtieran en macros, sería más fácil modificarlos. Bastaría con crear encabezados para ensamblador y encabezados para código C, y definir las estructuras con macros. Así el código C y el código ensamblador quedarían sincronizados. La desventaja es que habría que definir las estructuras con esas macros, pero eso solo aplicaría a las estructuras usadas en ensamblador y en C, o en niveles superiores.
• Hacía mucho que no escuchaba sobre ThreadX. Trabajé en un producto basado en ThreadX hace unos 20 años. No era un dispositivo de aplicación que necesitara planificación en tiempo real ni arranque rápido, pero la decisión de elegir ThreadX estaba fuera del nivel en el que yo podía influir. Incluso había un producto aparte "avanzado" que corría Linux embebido y daba gusto trabajar con él. Desarrollar, depurar y probar usando ThreadX tomaba entre 2 y 3 veces más tiempo. Eso se debía a que muchas de las comodidades de las que uno termina dependiendo en un kernel no existen en ThreadX. Solo recomendaría usarlo para dispositivos de seguridad crítica muy simples.
• Esto en realidad es algo grande, y es genial que Eclipse Foundation lo administre. Microsoft merece reconocimiento y elogios por esto. Tienen un buen historial, así que soy bastante optimista, pero este proyecto va a necesitar mucho soporte continuo. Ahora ya no será solo responsabilidad de Microsoft, aunque puede que carguen con una parte mayor mientras las cosas arrancan.
• Cuando trabajé en firmware para Deskjet, ThreadX era un RTOS decente. En ese tiempo, los sistemas operativos open source y especialmente las herramientas no eran adecuados para el trabajo. Pero ahora las cosas han cambiado mucho y sí hay alternativas.
• ThreadX no es open source. El código fuente está publicado, pero se ofrece como una versión de evaluación, es decir, bajo una licencia propietaria.