RTLinux

RTLinux es un microkernel de sistema operativo de tiempo real estricto (RTOS) que ejecuta todo el sistema operativo Linux como un proceso totalmente preemptivo . La propiedad de tiempo real estricto permite controlar robots, sistemas de adquisición de datos , plantas de fabricación y otros instrumentos y máquinas sensibles al tiempo desde aplicaciones RTLinux. A pesar del nombre similar, no está relacionado con el proyecto Real-Time Linux de la Fundación Linux . ^{[ 1 ]}

RTLinux fue desarrollado por Victor Yodaiken, Michael Barabanov, Cort Dougan y otros en el Instituto de Minería y Tecnología de Nuevo México , y posteriormente se comercializó en FSMLabs. Wind River Systems adquirió la tecnología integrada de FSMLabs en febrero de 2007 y lanzó una versión llamada Wind River Real-Time Core para Wind River Linux . En agosto de 2011, Wind River descontinuó la línea de productos Wind River Real-Time Core, poniendo fin al soporte comercial para RTLinux.

El objetivo clave del diseño de RTLinux ^{[ 2 ]} era agregar capacidades de tiempo real estricto a un sistema operativo comercial para facilitar el desarrollo de programas de control complejos con ambas capacidades. ^{[ 3 ] [ 4 ]} Por ejemplo, se podría querer desarrollar un controlador de motor en tiempo real que utilizara una base de datos comercial y exportara una interfaz de operador web. En lugar de intentar construir un único sistema operativo que pudiera admitir capacidades de tiempo real y no tiempo real, RTLinux fue diseñado para compartir un dispositivo de computación entre un sistema operativo de tiempo real y uno de no tiempo real de modo que (1) el sistema operativo de tiempo real nunca pudiera ser bloqueado de su ejecución por el sistema operativo de no tiempo real y (2) los componentes que se ejecutan en los dos entornos diferentes pudieran compartir datos fácilmente. Como su nombre lo indica, RTLinux fue diseñado originalmente para usar Linux como el sistema de no tiempo real ^{[ 5 ]} pero finalmente evolucionó para que el núcleo de tiempo real RTCore pudiera ejecutarse con Linux o Berkeley Software Distribution (BSD) Unix .

MERT ( Multi-Environment Real-Time ) fue el primer ejemplo de un sistema operativo en tiempo real que coexistía con un sistema Unix. MERT se basaba en técnicas de virtualización tradicionales : el núcleo en tiempo real era el sistema operativo anfitrión (o hipervisor ) y Bell Systems Unix era el sistema invitado . RTLinux fue un intento de actualizar el concepto de MERT a la era de los PC y al hardware comercial. También fue un intento de superar las limitaciones de rendimiento de MERT, en particular la sobrecarga introducida por la virtualización.

En lugar de encapsular el sistema operativo invitado en una máquina virtual , RTLinux virtualizó únicamente el control de interrupciones del invitado . Este método permitió que el núcleo en tiempo real convirtiera el sistema operativo invitado en un sistema completamente preemptivo, pero que aún podía controlar directamente, por ejemplo, los dispositivos de almacenamiento. En particular, los controladores estándar para el invitado funcionaban sin modificar el código fuente, aunque era necesario recompilarlos para usar los "ganchos" de virtualización. Véase también paravirtualización . La tubería de Unix se adaptó para permitir la comunicación entre programas en tiempo real y no en tiempo real, aunque también se añadieron otros métodos, como la memoria compartida.

Desde el punto de vista del programador, RTLinux originalmente parecía un pequeño entorno multihilo para tareas en tiempo real, además del entorno Linux estándar para todo lo demás. El sistema operativo en tiempo real se implementó como un módulo del kernel cargable que comenzaba virtualizando el control de interrupciones del sistema invitado y luego iniciaba un planificador en tiempo real. A las tareas se les asignaban prioridades estáticas y la planificación originalmente se basaba exclusivamente en prioridades. El sistema operativo invitado se incorporaba como la tarea de menor prioridad y, esencialmente, actuaba como la tarea inactiva para el sistema en tiempo real. Las tareas en tiempo real se ejecutaban en modo kernel . El desarrollo posterior de RTLinux adoptó la interfaz de programación de aplicaciones ( API ) de hilos POSIX ( Portable Operating System Interface ) y luego permitió la creación de hilos en modo usuario con hilos en tiempo real ejecutándose dentro de los procesos invitados. En entornos multiprocesador , los hilos estaban bloqueados a núcleos de procesador y era posible evitar que el hilo invitado se ejecutara en un núcleo designado (reservando efectivamente los núcleos solo para el procesamiento en tiempo real).

RTLinux permite ejecutar tareas especiales en tiempo real y manejadores de interrupciones en la misma máquina que Linux estándar. Estas tareas y manejadores se ejecutan cuando es necesario, independientemente de la actividad de Linux. El tiempo máximo entre la detección de una interrupción de hardware por parte del procesador y el inicio de la ejecución de un manejador de interrupciones es inferior a 15 microsegundos en RTLinux ejecutándose en un sistema x86 genérico (alrededor del año 2000). Una tarea periódica de RTLinux se ejecuta dentro de los 35 microsegundos de su tiempo programado en el mismo hardware. Estos tiempos están limitados por el hardware, y a medida que este mejore, RTLinux también lo hará. Linux estándar ofrece un excelente rendimiento promedio e incluso puede proporcionar una precisión de planificación a nivel de milisegundos para tareas que utilizan las capacidades de tiempo real flexible de POSIX. Sin embargo, Linux estándar no está diseñado para proporcionar una precisión inferior al milisegundo ni garantías de temporización fiables. RTLinux se basaba en una máquina virtual ligera donde el sistema Linux "invitado" disponía de un controlador de interrupciones y un temporizador virtualizados, y el acceso al resto del hardware era directo. Desde la perspectiva del sistema anfitrión en tiempo real, el núcleo de Linux se comporta como un hilo. Las interrupciones necesarias para el procesamiento determinista son procesadas por el núcleo en tiempo real, mientras que otras interrupciones se envían a Linux, que se ejecuta con menor prioridad que los hilos en tiempo real. Los controladores de Linux gestionan prácticamente todas las operaciones de entrada/salida . Se pueden utilizar tuberías FIFO (primero en entrar, primero en salir ) o memoria compartida para compartir datos entre el sistema operativo y RTLinux.

El objetivo principal del diseño de RTLinux es que el sistema sea transparente, modular y extensible . La transparencia implica que no existan mecanismos internos opacos y que el coste de cualquier operación sea determinable. La modularidad permite omitir funcionalidades y su coste si no son necesarias. Y la extensibilidad implica que los programadores puedan añadir módulos y adaptar el sistema a sus necesidades. El sistema base de RTLinux admite el manejo de interrupciones de alta velocidad, y nada más. Cuenta con un planificador de prioridades sencillo que puede sustituirse fácilmente por planificadores más adecuados a las necesidades de cada aplicación específica. Al desarrollar RTLinux, se diseñó para maximizar las ventajas de tener Linux y sus potentes capacidades a nuestra disposición.

RTLinux se estructura en un pequeño componente central y un conjunto de componentes opcionales. El componente central permite la instalación de manejadores de interrupciones de muy baja latencia que no pueden ser retrasados ​​ni interrumpidos por Linux, así como algunas rutinas de sincronización y control de interrupciones de bajo nivel. Este componente central se ha ampliado para admitir SMP y, al mismo tiempo, se ha simplificado eliminando algunas funcionalidades que pueden proporcionarse fuera del núcleo.

La mayoría de las funciones de RTLinux se encuentran en un conjunto de módulos del kernel cargables que proporcionan servicios opcionales y niveles de abstracción . Estos módulos incluyen:

1. rtl sched: un planificador de prioridades que admite tanto una interfaz "lite POSIX" descrita a continuación como la API RTLinux V1 original.
2. rtl time: controla los relojes del procesador y exporta una interfaz abstracta para conectar los manejadores a los relojes.
3. rtl posixio: admite una interfaz de lectura/escritura/apertura de estilo POSIX para controladores de dispositivos .
4. rtl fifo: conecta las tareas RT y los controladores de interrupciones con los procesos de Linux a través de una capa de dispositivo, de modo que los procesos de Linux puedan leer y escribir en los componentes RT.
5. semaphore: un paquete aportado por Jerry Epplin que proporciona semáforos de bloqueo para tareas RT .
6. Está previsto que la compatibilidad con mutex POSIX esté disponible en la próxima actualización menor de RTLinux.
7. mbuff es un paquete aportado por Tomasz Motylewski para proporcionar memoria compartida entre componentes RT y procesos Linux.

Las tareas en tiempo real de RTLinux se implementan como módulos del kernel, similares a los que Linux utiliza para controladores, sistemas de archivos , etc. Estas tareas tienen acceso directo al hardware y no utilizan memoria virtual . Al inicializarse, una tarea (módulo) en tiempo real informa al kernel de RTLinux sobre su fecha límite, período y restricciones de tiempo de lanzamiento.

RT-Linux implementa una API POSIX para la manipulación de hilos. Un hilo se crea llamando a la pthread_createfunción. El tercer parámetro de pthread_createes una función que contiene el código ejecutado por el hilo.

En RTLinux es necesario establecer prioridades para los hilos. Los hilos con mayor prioridad pueden interrumpir a los de menor prioridad. Por ejemplo, podemos tener un hilo controlando un motor paso a paso. Para que el motor se mueva con fluidez, es necesario iniciar este hilo a intervalos estrictamente regulares. Esto se garantiza asignándole una alta prioridad. El ejemplo threads2.c establece diferentes prioridades para los hilos. El código que se muestra a continuación permite configurar la prioridad de los hilos:

int init_module ( void ) { pthread_attr_t attr ; struct sched_param param ; pthread_attr_init ( & attr ); param.sched_priority = 1 ; pthread_attr_setschedparam ( & attr , & param ) ; pthread_create ( & t1 , & attr , & thread_code , " este es el hilo 1" ); rtl_printf ( "Hilo 1 iniciado \n " ); /* ... */ }

La salida del programa es la siguiente.

Hilo 1 iniciado Hilo 2 iniciado El hilo 3 ha comenzado. Mensaje: este es el hilo 1 Mensaje: este es el hilo 2 Mensaje: este es el hilo 2 Mensaje: este es el hilo 2 Mensaje: este es el hilo 1 Mensaje: este es el hilo 1 Mensaje: este es el hilo 3 Mensaje: este es el hilo 3 Mensaje: este es el hilo 3 

El hilo 2 tiene la máxima prioridad y el hilo 3 la mínima. El primer mensaje lo imprime el hilo 1, de prioridad intermedia, porque se inicia poco antes que el hilo 2.

• RTAI . RTAI comenzó como una variante de RTLinux llamada "MyRTlinux" y, en versiones posteriores, sus autores afirmaron que no utilizaba la técnica de virtualización patentada de RTLinux.
• RMX (sistema operativo)
• FECHA LÍMITE DEL PROGRAMA
• Xenomai
• Preemptividad (informática)
• Linux en sistemas embebidos
• Pruebas en tiempo real

• Artículo sobre la sincronización de RTLinux
• Un Linux en tiempo real archivado el 18 de marzo de 2007 en la Wayback Machine . Victor Yodaiken y Michael Barabanov, Instituto Tecnológico de Nuevo México.
• Enlace obsoleto en archive.today (archivado el 28/01/2013)