Barrapunto

No sé si todos los sistemas de tiempo real basados en Linux funcionan igual, pero al menos para este caso, RTLInux [windriver.com] (uno de los más populares) es un parche del kernel convencional.

... un Linux RTOS "de verdad"... y no un "chapú" ejecutándose debajo de otro sistema operativo.

Otros Unixes, como por ejemplo LynxOS y QNX proporcionan tiempo de respuesta acotado para *todo*. Cual comensal que es capaz de degustar un buen menú, si bien sólo tiene capacidades modestas como cocinero, puestos a desear, deseo:

1. Posibilidad de elegir en tiempo de ejecución entre distintos perfiles, por ejemplo:

1.1. "Hard RTOS (echo 1 >/proc/rtos): capaz de de garantizar un tiempo de respuesta acotado para cualquier evento (despacho de interrupción, evento IPC, señalización, sincronización, flush de buffers, etc.).
1.2. "Balanced Hard RTOS" (echo 3 >/proc/rtos): similar al anterior, incluyendo ponderación entre procesos, con un "quality of service" de tiempo de ejecución, para distintas necesidades.
1.3. "Selective Hard RTOS" (echo 5 >/proc/rtos): "Hard RTOS" a nivel de kernel, y configurable a nivel de aplicación, siendo un atributo más de las mismas (e.g. suscripción/demanda de tiempo de CPU necesario por cada 100ms, etc.).
1.4. "Responsive Soft RTOS" (echo 4 >/proc/rtos): similar a los parches que llevan introduciéndose en Linux, permitiendo hacer más interrumpible al kernel, cambios de contexto más frecuentes para sensación más fluida, etc.
1.4. "Throughput-focused OS" (echo 0 >/proc/rtos): tipo Unix clásico, e.g., todo el tiempo de proceso posible para tareas efectivas, sin importar demasiado el "cuando".
Un planificador capaz de lidiar con procesos con perfiles concretos de necesidades de respuesta acotada, capaz de interrumpir a cualquier thread, ya sea de un proceso de usuario o del kernel.

2. Elementos a considerar para que sean posibles los puntos anteriores:

2.1. Caché de disco: dos modos, una en modo RTOS y otro en modo Soft RTOS. En modo RTOS el tamaño de la cache y los buffers de escritura tienen que estar necesariamente acotados, para garantizar el tiempo de respuesta en el peor de los casos.
2.2. Planificador de ejecución de procesos ("process scheduler"): número máximo de procesos acotado en modo RTOS para garantizar el tiempo de respuesta. Si bien un planificador O(1) podría, en teoría, hacer este punto irrelevante, en la práctica, en operaciones de impliquen broadcasts de señales, "flushes" del sistema de archivos, etc., sí suponen un problema colateral, pese a tener un planificador espectacular.
2.3. Gestión de memoria en modo RTOS: limitar la capacidad de paginación por proceso, limitar la capacidad de consumo de RAM física a la cuarta parte de la memoria disponible, para poder tener 4 entornos de gestión de memoria globales (reducción de la fragmentación interna).
2.4. Desarrollo de drivers que se ejecuten o no en modo RTOS, tengan un tiempo de respuesta acotado, sean interrumpibles, tengan buffers de tamaño programable, con distintos modos de operación (buffers pequeños para poca latencia, etc.).
2.5. ... añade tus ideas, a ver si sale bueno el cocido!!

Parece que el barco de colegas [youtube.com] de Linux va por buen camino ;-)