Sistema Operativo de tiempo real QNX (página 2)

8. La Filosofía de QNX

Introducción

Las aplicaciones de tiempo real dependen del sistema operativo para manipular eventos múltiples dentro de restricciones fijas de tiempo.

El sistema operativo QNX es ideal para las aplicaciones de tiempo real. Proporciona multitarea, planificación por prioridades con desalojo, y rápido cambio de contexto.

QNX también es notablemente flexible. Desarrolladores pueden personalizar el sistema operativo fácilmente para satisfacer las necesidades de su aplicación. Desde la configuración del kernel en unos módulos pequeños, a un sistema de red amplia para servir cientos de usuarios.

QNX logra su único grado de eficacia, modularidad, y simplicidad a través de dos principios fundamentales:

• La arquitectura del Microkernel
• La comunicación entre procesos basada en mensajes.

La arquitectura del Microkernel de QNX

QNX consiste en un kernel pequeño a cargo de un grupo de procesos cooperativos.

Un verdadero kernel

El Microkernel de QNX es muy pequeño y se dedica a sólo dos funciones esenciales:

• Intercambio de mensajes: el Microkernel se ocupa de la asignación de ruta de todos los mensajes entre todos los procesos a lo largo de todo el sistema.
• Planificación: el scheduler es una parte del Microkernel y se invoca siempre que un proceso cambie el estado como el resultado de un mensaje o una interrupción.

A diferencia de los procesos, el propio Microkernel nunca se planifica para la ejecución o sea no participa en el scheduling. En él se entra sólo como el resultado directo de llamadas del kernel, ya sea de un proceso o de una interrupción del hardware.

Los procesos del sistema

Todos los servicios de QNX, excepto aquellos proporcionados por el Microkernel, se manejan como procesos comunes. Una configuración de QNX típica tiene los procesos de sistema siguientes:

• Administrador de procesos (Proc)
• Administrador del sistema de archivos (Fsys)
• Administrador de dispositivos (Dev)
• Administrador de red (Net)

Drivers de dispositivos

Los drivers de dispositivos son procesos que protegen al sistema operativo de tratar con todos los detalles requeridos para soportar hardware específico.

Agregar un nuevo driver a QNX no afecta al sistema operativo. El único cambio que usted necesita hacer a su ambiente de QNX es iniciar el nuevo driver.

QNX como un sistema operativo de intercambio de mensajes (IPC)

QNX fue el primer sistema operativo comercial de su tipo para hacer uso del intercambio de mensajes como significados verdaderos de IPC. QNX debe mucho de su poder, simplicidad, y elegancia a la integración completa de éste método a lo largo de todo el sistema.

En QNX, un mensaje es un paquete de bytes que pasa de un proceso a otro. QNX no le presta ningún significado al contenido de un mensaje – los datos en un mensaje tienen significado para el remitente del mensaje y para su receptor, pero para nadie más.

IPC también proporciona medios para sincronizar la ejecución de varios procesos. Sabiendo los estados y prioridades de cada proceso, el Microkernel puede realizar un scheduling sobre todos los procesos tan eficazmente como sea posible para hacer el mayor la disponibilidad de recursos de CPU.

QNX como una red

Cualquier proceso en cualquier máquina en la red puede hacer uso de cualquier recurso directamente en cualquier otra máquina. De la perspectiva de la aplicación, no hay ninguna diferencia entre un recurso local o remoto – ningún medio especial necesita ser construido en las aplicaciones para hacer uso de recursos remotos. ¡De hecho, un programa necesitaría un código especial para poder decir si un recurso, como un archivo o el dispositivo, estaba presente en la computadora local o estaba en algún otro nodo en la red!

Los usuarios pueden acceder a los archivos en cualquier parte en la red, aprovechar cualquier dispositivo periférico, y ejecutar aplicaciones en cualquier máquina en la red (siempre que ellos tengan la autoridad apropiada). Los Procesos pueden comunicarse de la misma manera a lo largo de la red entera.

SMP (Symmetric Multi-Processing)

SMP (Symmetric Multi-Processing) esta normalmente asociado con sistemas operativos como UNIX o NT. Estos sistemas con grandes kernels monolíticos tienden a ser bastante complejos, el resultado de muchos años de desarrollo. Puesto estos grandes kernels contienen la mayor parte de los servicios del sistema operativo, los cambios para soportar SMP son extensos, generalmente introduciendo muchas modificaciones en el código.

QNX por otro lado, contiene un microkernel muy pequeño rodeado por procesos que actúan como administradores de recursos, por ejemplo: sistemas de archivos, I/O, red. Modificando solamente el microkernel solamente, todos los demás servicios del sistema operativo ganaran inmediatamente una ventaja de SMP sin necesidad de cambios en el código. Si estos procesos son multihilo, cada uno de sus hilos será distribuido en los procesadores disponibles. Incluso en un servidor monohilo puede verse beneficiado por SMP, debido a que su hilo será ejecutado con mayor frecuencia.

Siguiendo la línea del microkernel de QNX, la versión SMP solo añade unos kilobytes mas de código. La versión actual permite bootear en un sistema que conforme la especificación Intel para multiprocesadores con hasta 8 procesadores pentium.

9. El Microkernel

Introducción

El Microkernel de QNX es responsable de lo siguiente:

• IPC – el Microkernel supervisa el ruteo de mensajes; también maneja otras dos formas de IPC: proxies y señales.
• La comunicación de la red a bajo nivel – el Microkernel entrega todos los mensajes destinados a los procesos en otros nodos.
• Scheduling de procesos – el scheduler del Microkernel decide qué proceso se ejecutará luego.
• Manejo de interrupciones del primer nivel – todas las interrupciones de hardware y las fallas se rutean primero a través del Microkernel, luego se pasa al driver o al administrador del sistema.

La comunicación entre procesos

El QNX Microkernel apoya tres tipos esenciales de IPC: mensajes, proxies y señales

• Mensajes – la forma fundamental de IPC en QNX. Ellos proporcionan la comunicación síncrona entre procesos cooperativos dónde el proceso que envía el mensaje requiere acuse de recibo y potencialmente una contestación al mensaje.
• Proxies – una forma especial de mensaje. Están especialmente preparados para notificación de eventos dónde el proceso que lo envía no necesita actuar recíprocamente con el destinatario.
• Señales – una forma tradicional de IPC. Se utilizan para apoyar la comunicación entre procesos de forma asíncrona.

Proceso de sincronización

El intercambio de mensajes no solo permite a los procesos pasarse datos entre ellos, sino que también proporciona un medio de sincronizar la ejecución de varios procesos que cooperan mutuamente.

IPC por la red

Una aplicación de QNX puede hablar con un proceso en otra computadora en la red como si estuviera hablando con otro proceso en la misma máquina. De la perspectiva de la aplicación, no hay ninguna diferencia entre un recurso local y remoto.

Este grado notable de transparencia es posible por los circuitos virtuales (VC), qué son los caminos que el Administrador de la Red proporciona para transmitir mensajes, proxies, y señales por la red.

Scheduling de procesos

El scheduler del Microkernel toma las decisiones de planificación cuando:

• Un proceso se desbloquea.
• El Quantum para el proceso corriente expira.
• El proceso corriente se desaloja.

Prioridades de procesos

En QNX, a cada proceso se le asigna una prioridad. El scheduler selecciona el próximo proceso para correr mirando la prioridad asignada a cada proceso que está en la cola de LISTOS (un proceso en la cola de LISTOS es uno capaz de usar el CPU). El proceso con la prioridad más alta se selecciona para ejecutarse.

La cola de listos para seis procesos (A-F) qué están LISTOS. Todos los otros procesos (G-Z) están BLOQUEADOS. El proceso A está corriendo actualmente. Los procesos A, B, y C están en la prioridad más alta.

Las prioridades asignadas al rango de procesos son de 0 (el más bajo) a 31 (el más alto). Se hereda la prioridad predefinida del padre a un proceso hijo.

Métodos de Scheduling

Para satisfacer las necesidades de varias aplicaciones, QNX proporciona tres métodos de planificación:

• FIFO.
• Round-robin.
• Adaptativa.

Cada proceso en el sistema puede correr usando cualquiera de estos métodos.

Recuerde que estos métodos de scheduling sólo se aplican cuando dos o más procesos que comparten la misma prioridad están LISTOS (es decir los procesos están compitiendo directamente entre sí). Si un proceso de prioridad superior se pone en LISTO, desaloja todos los procesos de baja-prioridad inmediatamente.

Planificación FIFO

En FIFO, un proceso seleccionado para correr continúa ejecutándose hasta que:

• Voluntariamente abandona el control (por ejemplo hace cualquier llamada al kernel).
• Es desalojado por un proceso de prioridad superior.

Dos procesos que corren a la misma prioridad pueden usar FIFO para asegurar la exclusión mutua a un recurso compartido. Ningún proceso será desalojado por el otro mientras se está ejecutando.

Planificación Round-robin

En Round-robin un proceso seleccionado para correr continúa ejecutando hasta que:

• Voluntariamente abandona el control.
• Es desalojado por un proceso de prioridad superior.
• Consume su quantum.

Un quantum es la unidad de tiempo asignada a cada proceso. Una vez que consume su quantum, un proceso se desaloja y el próximo proceso LISTO al mismo nivel de prioridad se le da el control. Un quantum es de 50 milliseconds.

Planificación adaptativa

En la planificación adaptativa, un proceso se comporta como sigue:

• Si el proceso consume su quantum (es decir no bloquea), su prioridad está reducida por 1. Esto se conoce como el decaimiento de prioridad. Notar que un el proceso "descendente" no continuará disminuyendo, aun cuando consume otro quantum sin bloquear; dejará caer la prioridad sólo un nivel por debajo de su prioridad original.
• Si el proceso bloquea, revierte inmediatamente a su prioridad original.

Usted puede usar la planificación adaptativa en ambientes dónde los procesos son del tipo background en su mayoría y están compartiendo la computadora con los usuarios interactivos.

La planificación adaptativa es el método de planificación predefinido para programas creados por la SHELL.

Latencia de interrupciones

La latencia de la interrupción es el tiempo de la recepción de una interrupción del hardware hasta que se ejecuta la primera instrucción de un manipulador de interrupción de software. QNX deja las interrupciones habilitadas casi todo el tiempo, para que la latencia de interrupción sea insignificante. Pero ciertas secciones críticas de código requieren que se desactive temporalmente las mismas. El máximo tiempo de desactivación de las interrupciones define la latencia de interrupción del peor caso, en QNX es muy pequeño.

La latencia de interrupción del peor caso será el tiempo más largo en que QNX desactiva las interrupciones de CPU.

La tabla siguiente muestra la latencia de interrupción típica cronometrada (Til) para un rango de procesadores:

Latencia del scheduling

Es el tiempo entre la terminación del manipulador de interrupción y la ejecución de la primera instrucción de un proceso del driver. Esto significa el tiempo que toma cambiar el contexto del proceso actualmente ejecutando y restaurar el contexto del proceso del driver requerido. Aunque es más grande que la latencia de la interrupción, este tiempo también es pequeño en un sistema de QNX.

10. El Administrador del Procesos

Responsabilidades del Administrador de procesos

El Administrador de Procesos trabaja estrechamente con el Microkernel para proporcionar los servicios del sistema operativo esenciales. Aunque comparte el mismo espacio de dirección con el Microkernel, el Administrador de Procesos corre como un verdadero proceso, por lo que también el Microkernel realiza scheluding sobre él.

El Administrador del Procesos es responsable de crear nuevos procesos en el sistema y manejar los recursos más fundamentales asociados con un proceso. Estos servicios son todos proporcionados vía mensajes. Por ejemplo, si un proceso corriente quiere crear un nuevo proceso, envía un mensaje que contiene los detalles del nuevo proceso a ser creado. Note que desde que los mensajes pueden enviarse a través de la red, usted puede crear un proceso fácilmente en otro nodo enviando el mensaje de creación de proceso al Administrador del Procesos en ese nodo.

Primitivas de creación de procesos

QNX apoya tres primitivas:

• Fork ()
• Exec ()
• Spawn ()

Fork () y exec () se definen por POSIX, mientras que la implementación de spawn() es única a QNX.

• Fork () crea un nuevo proceso que es una imagen exacta del proceso que la invocó. El nuevo proceso comparte el mismo código que el proceso que invocó la primitiva y hereda una copia de los datos del mismo.
• Exec () reemplaza la imagen del proceso que la invoca con una nueva imagen del mismo.
• Spawn() crea un nuevo proceso como un hijo del proceso invocante. Puede evitar la necesidad de fork () y exec (), produciendo un medio más rápido y más eficaz para crear nuevos procesos. La primitiva spawn() puede crear procesos en cualquier nodo en la red.

El ciclo de vida de un proceso

Un proceso pasa por cuatro fases:

• Creación
• Carga
• Ejecución
• Terminación

Creación

Crear un proceso consiste en asignar un PID para el nuevo proceso y preparar la información que define el ambiente del nuevo proceso. La mayoría de esta información se hereda del padre del nuevo proceso.

Carga

La carga de imágenes del proceso se hace por un hilo del LOADER. El código del LOADER reside en el Administrador del Procesos, pero el hilo corre bajo el PID del nuevo proceso. Esto permite al Administrador de Procesos atender otras demandas mientras los programas se cargan.

Ejecución

Una vez que el código del programa se ha cargado, el proceso está listo para la ejecución; empieza a competir con otros procesos por los recursos de CPU. Nótese que todos los procesos se ejecutan concurrentemente con sus padres. Además, la muerte de un proceso padre no causa la muerte de sus procesos hijos automáticamente.

Terminación

Un proceso se termina de dos maneras:

• Por una señal cuya acción cause la terminación deliberada del proceso.
• El proceso invoca exit (), explícitamente o por defecto la acción al volver al principal ()

La terminación involucra dos fases:

2. Un hilo de terminación en el Administrador del Procesos se ejecuta. Este código está en el Administrador del Procesos pero el hilo corre con el PID del proceso a terminar. Este hilo cierra todos los descriptores de archivo abiertos y libera lo siguiente:

• Cualquier circuito virtual sostenido por el proceso.
• Toda la memoria asignada al proceso.
• Cualquier nombre simbólico.
• Cualquier número de dispositivo (Administrador de I/O).
• Cualquier manipulador de interrupciones.
• Cualquier proxie.
• Cualquier cronómetro.

Después de que el hilo de terminación se corre, la notificación de terminación del proceso se envía al proceso padre (esta fase corre dentro del Administrador del Procesos).

Si un proceso se termina por la entrega de una señal de terminación y la utilidad del dumper está corriendo, se genera un vuelco de memoria.

Estados del proceso

Un proceso siempre está en uno de los estados siguientes:

• LISTO: el proceso es capaz de usar el CPU (es decir no está esperando por cualquier evento a ocurrir).
• BLOQUEADO: el proceso está en uno de los siguientes estados bloqueados:
• • Enviar-bloqueado.
  • Recibir-bloqueado
  • Contestación-bloqueado
  • Señal-bloqueado
  • Semáforo-bloqueado
• RETENIDO: el proceso ha recibido una señal de SIGSTOP. Hasta que se remueva del estado RETENIDO, al proceso no se le permite usar el CPU; la única manera de quitarlo del estado RETENIDO es enviarle una señal de SIGCONT o terminar el proceso vía una señal.
• ESPERA –bloqueado: el proceso ha emitido una llamada WAIT () o WAITPID () para esperar por el estado de uno o más de sus procesos hijos.
• MUERTO – el proceso ha terminado pero es incapaz de enviar su estado de salida a su padre porque el padre no ha emitido un WAIT () o WAITPID (). UN proceso MUERTO tiene un estado, pero la memoria que ocupó una vez se ha liberado. Un proceso MUERTO también es conocido como un proceso zombi.

Nombres simbólicos para procesos

En QNX, la solución es permitir a los procesos darse un nombre simbólico. En el contexto de un solo nodo, los procesos pueden registrar este nombre con el Administrador del Procesos en el nodo dónde ellos se están ejecutando. Otros procesos pueden pedirle el PID asociado a ese nombre entonces al Administrador del Procesos.

Timers

Administración de timers

En QNX, la administración de tiempo se basa en un cronómetro del sistema mantenido por el sistema operativo. El cronómetro contiene Coordenadas de Tiempo Universal (UTC) relativo a 0 horas, 0 minutos, 0 segundos, el 1 de enero de 1970.

Facilidades avanzadas

Un proceso también puede crear timers, puede armarlos con un intervalo de tiempo, y puede quitar los mismos. Los medios de cronometrado avanzados son basados en POSIX Std 1003.1b.

La precisión del cronómetro

Usted puede setear la precisión de los cronómetros usando la utilidad del ticksize o la función qnx_ticksize (). Usted puede ajustar la precisión de 500 microseconds a 50 milliseconds.

Manipuladores de interrupciones

Ellos reaccionan a las interrupciones del hardware y manejan el traslado de bajo nivel de datos entre la computadora y los dispositivos externos.

Son empaquetados físicamente como la parte de un proceso QNX normal (por ejemplo un Driver), pero ellos siempre corren asincrónicamente con el proceso asociados con ellos.

Un manipulador de interrupciones:

• Se entra con una Far Call, no directamente por la propia interrupción (esto puede escribirse en C, en lugar de assembler).
• Se ejecuta incluido en el contexto del proceso, por lo que tiene acceso a todas las variables globales del proceso.
• Corre con las interrupciones habilitadas, pero solo se desaloja si una interrupción de prioridad superior ocurre.
• No debería hablar directamente con la interrupción de hardware 8259 (el sistema operativo se encarga de esto).
• Debe ser tan corto como sea posible.

Varios procesos se pueden atar a la misma interrupción (si es soportado por el hardware). Cuando una interrupción física ocurre, se le dará el mando a cada manipulador de interrupción de a uno a la vez.

11. I/O Namespace

El espacio de nombres de I/O

Los recursos de I/O no están construidos en el Microkernel de QNX. Los servicios de I/O son proporcionados por procesos que pueden ejecutarse dinámicamente mientras el sistema está corriendo. El filesystem de QNX es optativo, el espacio del pathname no se construye en el filesystem como en la mayoría de los sistemas monolíticos.

Los prefijos y regiones de autoridad

Con QNX, el espacio del pathname es dividido en regiones de autoridad. Cualquier proceso que desea proporcionar los servicios de I/O orientado a archivos registrará un prefijo con el Administrador del Procesos que define la porción del espacio de nombres que él desea administrar (es decir su región de autoridad). Estos prefijos constituyen un árbol de prefijos que se mantiene en la memoria en cada computadora que corre QNX.

Administrador prefijos I/O

Cuando un proceso abre un archivo, el pathname del archivo es aplicado contra el árbol de prefijos para direccionar el OPEN () al Administrador recursos I/O apropiado. Por ejemplo, el Administrador de Dispositivos de carácter (Dev) normalmente registra el prefijo /dev. Si un proceso llama OPEN () con /dev/xxx, una concurrencia con el prefijo de /dev ocurrirá y OPEN () se redireccionará a Dev (su dueño).

Network root

QNX apoya el concepto de súper o network root que te permiten aplicar un pathname contra el árbol de prefijos de un nodo específico. Esto también permite fácilmente que acceder a los archivos y dispositivos que no están en el espacio de nombres de su nodo. Por ejemplo, en una red de QNX típica los caminos siguientes se trazarían:

• /dev/ser1 el puerto de serie local
• / /10/dev/ser1 el puerto de serie en nodo 10
• / /0/dev/ser1 el puerto de serie local
• / /20/usr/dtdodge/test se archiva en nodo 20

Note que / /0 siempre se refieren al nodo local.

Alias

Una segunda forma de prefijo, es conocida como un alias, es una simple substitución de un string para un prefijo. Un alias es de la forma:

Prefijo =string reemplazante

Por ejemplo, asuma usted está corriendo en una máquina que no tiene un filesystem local (no hay ningún proceso que para administrar" /"). Sin embargo hay un filesystem, en otro nodo (diga 10) que usted desea acceder como" /". Usted logra esto usando el prefijo del seudónimo siguiente:

/ = / /10 /

Creando nombres del dispositivo especiales

Usted también puede usar alias para crear nombres de dispositivos especiales. Por ejemplo, si un spooler de impresión estuviera corriendo en el nodo 20, usted puede poner un pathname de la copiadora local como un alias a este de la siguiente forma:

/dev/printer=//20/dev/spool. Cualquier demanda para abrir /dev/printer se dirigirá por la red al spooler real.

Espacio de nombres del descriptor de archivos

Una vez que un recurso de I/O se ha abierto, un espacio de nombres diferente entra en acción. OPEN () retorna un entero llamado descriptor del archivo (FD) qué se usa para dirigir todas las demandas de I/O a ese Administrador.

El espacio de nombres de descriptor de archivos es completamente local a cada proceso. El Administrador usa una combinación de un PID y FD para identificar la estructura de control asociada con él la llamada OPEN () anterior. Esta estructura se llama Open Control Block (OCB) y se contiene dentro del Administrador de I/O.

El diagrama siguiente muestra a un Administrador de I/O que toma algún PID, FD mapeándolos y trazándolos a OCB.

El PID y FD trazan a un OCB de un Administrador de I/O.

Open Control Blocks (OCB)

El OCB contiene la información activa sobre el recurso abierto. Por ejemplo, el filesystem guarda el corriente punto de seek dentro del archivo dentro de esta estructura. Cada open () crea un nuevo OCB. Por consiguiente, si un proceso abre el mismo archivo dos veces, cualquier llamada al lseek () usando un FD no afectarán el punto seek del otro FD.

Lo mismo es válido para la apertura del mismo archivo por diferentes procesos.

El diagrama siguiente muestra dos procesos, en cuál un proceso abre el mismo archivo dos veces, y el otro lo abre una vez. No hay ningún FD compartido.

Muchos FD en uno o más procesos pueden referirse al mismo OCB. Esto es cumplido por dos medios:

• Un proceso puede usar dup (), dup2 (), o fcntl () funciones para crear un descriptor de archivo duplicado que se refiere al mismo OCB.
• Cuando un nuevo proceso se crea vía fork (), spawn (), o exec (), todos los descriptores de archivo abiertos se heredan por defecto por el nuevo proceso; estos descriptores heredados se refieren al mismo OCB como el descriptor de archivo correspondiente en el proceso padre.

Cuando varios FD se refieren al mismo OCB, entonces cualquier cambio en el estado del OCB se ve inmediatamente por todos los procesos que tienen el descriptor de archivo unido al mismo OCB.

El diagrama siguiente muestra dos procesos en cuál uno abre un archivo dos veces, entonces hace un dup () para conseguir un tercero. El proceso crea a un hijo que hereda todos los archivos abiertos.

Usted puede prevenir que un descriptor de archivo pueda heredarse cuando usted llama a un SPAWN () o exec () llamando a la función fcntl ()y seteando la bandera de FD_CLOEXEC.

12. El Administrador del Filesystem

Introducción

El Administrador de Filesystem (Fsys) proporciona un método estándar de guardar y acceder a los datos en los subsistemas de discos. Fsys es responsable de ocuparse de todas las demandas para abrir, cerrar, leer, y escribir los archivos.

¿Qué es un archivo?

En QNX, un archivo es un objeto que puede escribirse, leerse, o ambos. QNX implementa seis tipos de archivos; de los cuales cinco de éstos son manejados por Fsys:

• Archivos regulares – consisten en secuencia de bytes que pueden ser accedidas de forma aleatoria y no tiene ninguna otra estructura predefinida.
• Los directorios – contienen la información necesaria para localizar los archivos regulares; también contienen información del estado y los atributos para cada archivo regular.
• Simbolic links (accesos directos) – contienen un pathname a un archivo o directorio que será accedido en lugar del archivo simbolic link. Estos archivos se usan a menudo para proporcionar múltiples caminos a un solo archivo.
• Pipes y FIFOs – sirven como canales I/O entre procesos que cooperan.
• Archivos de bloques especiales – refiere a los dispositivos, como las unidades de disco, cintas, y particiones de la unidad de disco. Estos archivos normalmente se acceden de una manera que esconde las características del hardware del dispositivo de las aplicaciones.

El sexto tipo de archivo, el archivo especial de carácter, se maneja por el Administrador de Dispositivos.

Fecha y time stamps

Fsys mantiene cuatro tiempos diferentes por cada archivo:

• la fecha de último acceso (lea)
• La fecha de la última escritura.
• la fecha de última modificación
• la fecha de creación (único a QNX)

Acceso a archivos

El acceso a los archivos regulares y los directorios son controlados por bits de modo guardados en el inode del archivo.. Hay tres calificadores de acceso:

• Usuario únicamente.
• Grupo únicamente.
• Otros.

Un proceso también puede correr con el user ID o el group ID de un archivo en lugar de aquellos de su proceso padre. El mecanismo que permite esto está llamando el setuid ( setea el user ID en tiempo de ejecución)) y setgid (el Group ID).

Archivos regulares y directorios

Archivos regulares

QNX ve un archivo regular como una secuencia accesible de bytes en forma aleatoria que no tienen una estructura interior predefinida. Los programas de aplicación son responsables para entender la estructura y contenido de cualquier archivo regular.

Los directorios

Un directorio es un archivo que contiene entradas de directorio. Cada entrada de directorio asocia un nombre de archivo con un archivo. Un nombre de archivo es el nombre simbólico que permite identificar y acceder a un archivo. Un archivo puede identificarse por más de un nombre de archivo.

Los funcionamientos del directorio

El Administrador del Filesystem impone algunas restricciones en las operaciones que usted puede realizar en un directorio. Específicamente, usted no puede abrir un directorio para escribir en él.

Operaciones sobre directorios

Para leer las entradas del directorio, usted usa un juego de funciones POSIX definidas que proporcionan el acceso a las entradas del directorio en una forma independiente al SO. Estas funciones incluyen:

• opendir ()
• readdir ()
• rewinddir ()
• closedir ()

Extends

En QNX, se guardan archivos regulares y archivos del directorio como una sucesión de extends. Un extend es un conjunto de bloques consecutivos en el disco.

Donde se guardan los extends

Archivos que tienen sólo un extend almacenan la información del mismo en la entrada del directorio. Pero si más de un extend se necesita para almacenar el archivo, la información de éste se guarda en uno o más bloques extends anidados. Cada bloque extend puede sostener información de localización para 60 extends.

Un archivo que consiste en múltiples regiones consecutivas en un disco – llamadas extends en qnx.

Extendiendo archivos

Cuando el Administrador de Filesystem necesita extender un archivo cuyo último extend está completo, intenta primero extender el último extend, aun cuando sea sólo por un bloque. Pero si éste no puede extenderse, una nuevo extend es agregado.

Para asignar nuevos extends, el Administrador del Filesystem usa la política " First Fit". Una tabla especial en el Administrador del Filesystem contiene una entrada para cada bloque representado en el archivo "/. bitmap" (este archivo se describe en la sección. Cada entrada define el extend libre inmediato más grande en el área definida por su bloque correspondiente. El Administrador del Filesystem escoge la primera entrada en esta tabla, lo bastante grande para satisfacer la demanda para un nuevo extend.

Links e Inodes

En QNX, los archivos de datos pueden ser los referenciados por más de un nombre. A cada nombre de archivo se lo llama link. (Hay dos tipos de links: links duros a los que nosotros simplemente nos referimos como "links" y los simbolic links).

Para soportar links para cada archivo, el nombre de archivo está separado de la información que describe al archivo. La información que no pertenece al nombre de archivo se guarda en una tabla de almacenamiento llamada inode ( "nodo de información").

Si un archivo tiene sólo un link (es decir un nombre de archivo), la información del inode se guarda en la entrada del directorio para el archivo. Si el archivo tiene más de un link, el inode se guarda como un registro en un archivo especial nombrado / .inodes, y la entrada del directorio del archivo que apunta al registro del inode.

Usted sólo puede crear un link a un archivo si el archivo y el link están en el mismo filesystem.

El mismo archivo es el referenciado por dos links llamados "more" y "less."

Hay otras dos situaciones en que un archivo puede tener una entrada en el archivo de /.inodes:

• Si el filename de un archivo es más largo que 16 caracteres, la información del inode se guarda en el archivo / .inodes, haciendo lugar para un filename de 48 caracteres en la entrada del directorio.
• Si un archivo tiene más de un link y todos los links menos uno han sido quitados, el archivo continúa teniendo un archivo separado / .inodes en la entrada del mismo.

Removiendo links

Cuando se crea un archivo se le da una cuenta de links igual a uno. A medida que se agregan links al archivo, esta cuenta de links se incrementa; cuando se remueven links la cuenta se decrementa. El espacio que ocupa en disco el archivo no puede ser liberado a menos que la cuenta de links sea igual a cero y que todos los programas que usan el archivo lo hayan cerrado. Esto permite que un archivo abierto pueda seguir siendo utilizado aun cuando se hayan removido todos los links.

Simbolic Links

Es un archivo especial que tiene un pathname como dato. Cuando se nombra en una demanda de I/O – por Open(), por ejemplo – la parte del pathname del link se reemplaza por los "datos" del simbolic link y el path se reevalúa. Los simbolic links son medios flexibles de indirección del pathname y se usan a menudo para proporcionar caminos múltiples a un solo archivo. Al contrario que los links duros, estos pueden cruzar filesystems y también pueden crear links a directorios.

/ /1/usr/eric/src/test.c–> / /1/usr/src/game.c

El PID y FD trazan a un OCB de un Administrador de I/O.

Recuerde que quitando un link simbólico actúa sobre el link, no sobre el target.

Ya que los simbolics links pueden apuntar a directorios, las configuraciones incorrectas pueden producir problemas como links de directorios circulares. Para recuperarse de las referencias circulares, el sistema impone un límite en el número de saltos

Pipes

Un pipe es un archivo anónimo que sirve como un canal de I/O entre dos o más procesos que cooperan – un proceso escribe en el pipe y el otro lee del mismo. El Administrador del Filesystem cuida el buffering de los datos.

Normalmente se usan pipes cuando dos procesos quieren correr en paralelo, con datos que se mueven de un proceso al otro en una sola dirección. (Si la comunicación es bidireccional deben usarse mensajes)

Performance del Administrador de Filesystem

El Administrador de Filesystem tiene varias características que contribuyen a que el acceso al disco sea de alto rendimiento:

• Método de búsqueda del ascensor para el seek
• Cache de buffer
• multi-threading
• Prioridad que maneja el usuario
• Archivos temporales
• Ramdisks

Método de búsqueda del ascensor.

Minimiza el tiempo global de seek para leer o escribir los datos de o al disco. Las demandas de I/O son ordenadas de tal forma que todas puedan ser atendidas con una sola barrida del cabezal del disco, de la dirección más baja del disco a la más alta.

Cache de buffer

Es un buffer inteligente entre el Administrador del Filesystem y el driver del disco. El caché de buffer intenta guardar bloques del filesystem para minimizar el número de veces que el Administrador del Filesystem tiene que acceder el disco. Por defecto, el tamaño del caché es determinado por la memoria total del sistema, pero usted puede especificar un tamaño diferente vía una opción a Fsys.

Las operaciones de lectura son síncronas. Las escrituras, por otro lado, son normalmente asíncronas. Cuando los datos entran en el caché, el Administrador del Filesystem avisa al cliente que los datos fueron escritos. Los datos se escriben lo más pronto posible al disco, típicamente en menos de cinco segundos.

Las aplicaciones pueden modificar la conducta de las escrituras en un comportamiento de archivo-por-archivo. Por ejemplo, una aplicación de base de datos puede causar que todas las escrituras para un archivo dado deban ser realizadas sincrónicamente. Esto aseguraría un nivel alto de integridad del archivo ante problemas potenciales de hardware o suministro de energía que podrían dejar una base de datos en un estado incoherente.

Multi-threading

El Administrador del Filesystem es un proceso multi-hilo. Es decir, puede manejar varios pedidos de I/O simultáneamente. Esto le permite al Administrador del Filesystem totalmente aprovecharse del potencial del paralelismo de la siguiente forma:

• Acceso varios dispositivos en paralelo.
• Satisfacer demandas de I/O desde el caché de buffer mientras otras peticiones que acceden al disco son atendidas.

La prioridad del usuario

El Administrador del Filesystem puede tener su prioridad manejada por la prioridad de los procesos que le envían mensajes. Cuando el Administrador del Filesystem recibe un mensaje, se le asigna la prioridad del proceso que realizó la petición.

Ramdisks

El Administrador de Filesystem tiene una capacidad de ramdisk integrada que permite que 8M de memoria puedan ser usados como un disco simulado

El Administrador del Filesystem puede desviase del caché porque el ramdisk esta incorporado a él y no necesita un driver.

La robustez de Filesystem

El filesystem de QNX logra un throughput alto sin sacrificar la fiabilidad. Esto se cumple de varias maneras.

Mientras la mayoría de los datos se almacena en el caché y son escritos después de un retraso corto, los datos críticos del filesystem se escriben inmediatamente. Las actualizaciones de los directorios, inodes, los bloques extends, y los bitmap se envían forzosamente al disco para asegurar que la estructura del filesystem en el disco nunca sea incoherente.

La recuperación de Filesystem

Para que usted pueda recuperar tantos archivos como sea posible, únicas "firmas" han sido escritas en el disco para ayudar en la identificación automática y recuperación de los pedazos del filesystem críticos. Los archivos inodes (/ .inodes), así como cada directorio y extends blocks, contienen únicos modelos de datos que la utilidad del chkfsys puede usar para volver a montar un filesystem dañados.

Los discos y subsistemas del disco

QNX considera cada disco físico en una computadora como un bloque el archivo especial. Un disco se ve por el filesystem de QNX como un conjunto secuencial de bloques, de 512 bytes en el tamaño cada uno, sin tener en cuenta el tamaño y capacidad del disco. Se numeran los bloques, empezando con el primer bloque en el disco (bloque 1).

Una computadora QNX corriente puede tener uno o más subsistemas del disco. Cada subsistema del disco consiste en controlador y uno o más discos. Usted inicia el driver del dispositivo para cada subsistema del disco que será manejado por el Administrador de Filesystem.

Particiones de SO

QNX cumple con el estándar de la industria que permite tener distintos sistemas operativos sobre el mismo disco. De acuerdo con esto se puede definir una tabla de partición de hasta cuatro particiones primarias sobre el disco. La tabla se almacena en el primer bloque del disco. QNX trata a cada partición en un disco como un bloque el archivo especial.

Cada partición debe tener un tipo reconocido por el SO. Aquí se muestran los tipos de particiones que se usan generalmente:

Los componentes importantes de una partición de QNX

Los componentes importantes se encuentran juntos al principio de cada partición QNX:

• el bloque loader
• el bloque root
• el bitmap
• el directorio del root

Estas estructuras se crean cuando usted inicializa el filesystem con la utilidad del dinit.

La estructura de un filesystem de QNX dentro de una partición del disco.

El bloque loader

Éste es el primer bloque físico de una partición del disco. Este bloque contiene el código que se carga y se ejecuta por el BIOS de la computadora para cargar un sistema operativo de la partición. Si un disco no se ha dividido (por ejemplo como en un floppy), este bloque es el primer bloque físico en el disco.

El bloque root

El bloque de la raíz se estructura como un directorio normal. Contiene la información del inode para estos cuatro archivos especiales:

• el directorio de la raíz del filesystem (/)
• / .inodes
• / .boot
• / .altboot

Normalmente, el loader de QNX carga la imagen de OS guardada en el archivo /.boot. Pero si el archivo de /.altboot no está vacío, se dará la opción para cargar la imagen guardada en el archivo de /.altboot.

Bitmap

Para asignar el espacio en un disco, QNX usa un bitmap guardado en el archivo /.bitmap. Este archivo contiene un mapa de todos los bloques en el disco, indicando qué bloques están usados. Cada bloque se representa por un bit. Si el valor del bit es 1, su bloque correspondiente en el disco está usándose.

Borrado de archivos

Cuando un directorio o el archivo se borra, la estructura de datos que lo representa es marcada como borrada, pero no se remueve la misma. Esto evita borrar continuamente y volver a escribir el medio.

Eventualmente, el medio se quedará sin espacio libre y el Administrador del filesystem realizará el reclamo de espacio (o "Garbage Collector"). Durante este proceso, Efsys. * recupera el espacio ocupado por los archivos anulados y directorios.

NFS FILESYSTEM

Originalmente desarrollado por el Sun Microsystems, el Sistema de Archivo de Red (NFS) es una aplicación de TCP/IP que se ha llevado a cabo subsecuentemente en DOS y sistemas de Unix.

QNX soporta este tipo de fileSystems. Usted necesita sólo usar NFS si está accediendo a filesystems que no son QNX NFS, o si usted quiere permitir a los clientes de NFS acceder al espacio de nombres de QNX.

NFS le permite unir filesystems remotos – o porciones de ellos – hacia su espacio de nombres local. Los directorios en los sistemas remotos aparecen como parte de su filesystem local y todas las utilidades que usted usa para listar y manejar los archivos (por ejemplo el ls, el cp, el mv) operan exactamente igual en los archivos remotos como lo hacen en sus archivos locales.

13. El Administrador del Dispositivo

Introducción

El QNX Administrador de Dispositivos (Dev) es la interfase entre los procesos y los dispositivos terminales. Estos dispositivos terminales se localizan en el namespace de I/O con nombres que comienzan con /dev. por ejemplo, un dispositivo de la consola en QNX tendría un nombre como:

Los servicios de dispositivos

Un dispositivo terminal se presenta a un proceso de QNX como un flujo bidireccional de bytes que pueden leerse o pueden escribirse por el proceso.

El Administrador del Dispositivos regula el flujo de datos entre una aplicación y el dispositivo. Algo del procesamiento de los datos es realizado por Dev según los parámetros en una estructura de control terminal (llamada el termios) que existe para cada dispositivo.

Los parámetros del termios controlan la funcionalidad de bajo nivel como:

• la disciplina de línea de mando (incluso la proporción del baudio, paridad, los bits de stop y los bits de datos)
• Eco de caracteres
• Edición de la línea de entrada
• Reconocimiento y solución sobre pausas y cortes
• Control de flujo por hardware y software
• la traducción de caracteres salida

Driver de Dispositivos

La ilustración siguiente muestra un subsistema típico de un dispositivo en QNX.

El proceso de Administrador de Dispositivos (Dev) maneja el flujo de datos a y de los procesos de aplicación QNX. La interfase del hardware se maneja por procesos de drivers individuales. El dato fluye entre Dev y sus drivers a través de un conjunto de colas de memoria compartida para cada dispositivo terminal.

Ya que se usan colas de memoria compartida, es necesario que Dev y todos sus drivers residan en el mismo CPU físico. La ventaja es que se incrementa la Performance.

Se usan tres colas para cada dispositivo. Cada cola se implementa usando FIFO. Una estructura de control también es asociada con cada cola.

Los datos recibidos se ponen en la cola de entrada por el driver y sólo se consume por Dev cuando la aplicación procesa los datos de la demanda.

Los tamaños de todas estas colas son configurables por el administrador del sistema; la única restricción es que el total de la suma de las tres colas no puede exceder 64K. Los valores por defecto normalmente son más que adecuados para manejar la mayoría de las configuraciones del hardware.

Control de Dispositivos

Los drivers de dispositivos agregan los datos recibidos simplemente a la cola de la entrada o consumen y transmiten los datos de la cola de salida. Dev decide cuando (y si) la transmisión de salida será suspendida, etc.

Para asegurar una buena respuesta interactiva a eventos de entrada, Dev debe correr a una prioridad bastante alta.

Los drivers son procesos como cualquier otro proceso en QNX; ellos pueden ejecutarse a prioridades diferentes según la naturaleza del hardware a los que ellos están sirviendo

La consola de QNX

Las consolas del sistema son manejadas por el driver procesos "Dev.con". El adaptador de la placa de video y la pantalla, más el teclado del sistema, están conjuntamente llamado la consola.

QNX permite correr las sesiones múltiples concurrentemente en las consolas por medio de las consolas virtuales. El proceso del driver de la consola "Dev.con" típicamente maneja más de un conjunto de colas de I/O a Dev que son disponibles para los procesos del usuario como un conjunto de dispositivos terminales con los nombres como /dev/con1, /dev/con2, etc.

Por supuesto que hay sólo una pantalla física y solo un teclado, entonces solo una de estas consolas virtuales realmente se despliega en cualquier único instante de tiempo. El teclado se asigna a la consola virtual que esta visible en ese instante.

El driver de las consolas QNX corre como un proceso normal QNX. Los caracteres de entrada por teclado son trazados por el manipulador de interrupciones del teclado y los coloca directamente en la cola de la entrada. Los datos de salida se consumen y despliegan por Dev.con.

14. Administración de memoria

¿QNX Soporta un archivo Swap?

No. hay algunos planes para llevar a cabo esto en algún momento en el futuro. Hay

otros rasgos que se agregarán a QNX antes de que un archivo Swap sea agregado. La razón principal de esto es que requerir tiempos de respuesta y performance en tiempo real tiene conflictos a la hora de implementar un archivo swap.

El requerimiento para swaping en la mayoría de las aplicaciones de QNX es bastante bajo.

La eficacia del OS y el copilador de Watcom proporcionan relativamente pequeños procesos en término de requisitos de memoria. Cuando esto se combina con

la habilidad de compartir el código entre las invocaciones de proceso múltiples y

las bibliotecas compartidas, las demandas de memoria en QNX son bastante moderadas.

¿ QNX soporta memoria virtual?

Sí. No confunda esto con un archivo swap. La memoria virtual sólo se refiere realmente al mapeo de memoria física a través de un MMU. QNX opera en modo protegido en los procesadores de Intel, y hace el uso de LDT y GDT para proveer un mapeo de memoria en la memoria física. El uso de memoria virtual permite que QNX provea tanto memoria compartida en una base por proceso como protección de memoria entre procesos aún entre los procesos que constituyen el mismo SO.

Protección de memoria

Mientras muchos de los kernels de tiempo real proveen soporte para la protección de memoria en tiempo de desarrollo, pocos los hacen para el momento de ejecución, con la performance como principal razón. Pero desde que la protección de memoria se esta haciendo común en muchos procesadores embebidos, la performance decae muy poco. La ventaja clave ganada por añadir memoria protegida, especialmente para sistemas de misión critica, es la robustez. Con protección de memoria, si uno de los procesos ejecutándose en un ambiente multitarea intenta acceder a memoria que no ha sido explícitamente declarada o alocada, el hardware MMU puede notificar al sistema operativo, que puede luego abortar el hilo.

Memory Management Units (MMUs)

Un típico MMU opera dividiendo la memoria física en un paginas de 4K. El hardware del procesador luego hace uso de un conjunto de tablas almacenadas en la memoria del sistema que definen el mapeo de direcciones virtuales a las direcciones emitida por el CPU para acceder memoria física. Mientras el hilo se ejecuta, direcciona la memoria como si lo hiciera en un sistema sin MMU, excepto que las tablas de paginas administradas por el sistema operativo controla como estas direcciones se mapean en la memoria física.

Para espacios de direcciones muy grandes con muchos procesos e hilos, el numero de entradas en la tabla de paginas puede ser significativo – mas de lo que puede almacenar el procesador. Para mantener la performance el procesador cachea frecuentemente las porciones usadas de las paginas de tablas en un TLB (translation look-aside buffer).

Los servicios de fallos en el caché TLB es parte de la sobrecarga impuesta por el uso de MMU. QNX usa varios arreglos inteligentes para minimizar esta sobrecarga.

Asociados a estas tablas de paginas hay bits que definen los atributos de cada pagina de memoria. Las paginas puede ser marcadas como solo lectura, lectura-escritura, etc…

Cuando QNX ejecuta un context switch, manipula la MMU para usar potencialmente un conjunto nuevo de paginas para el nuevo hilo. Si se esta cambiando entre hilos de un mismo proceso, no se requieren manipulaciones del MMU.

Tipo de protección de memoria

El costo de performance por protección de memoria es insignificante en la mayoría de los sistemas. Quizás más importante es el incremento de costo de memoria para soportar las tablas de paginas MMU para implementar mayor nivel de protección.

El administrador de procesos ofrece la posibilidad de ninguna protección o protección total.

Sin protección

En este modelo, todos los procesos (kernel y usuarios) corren en el mismo espacio de memoria compartida.

Protección total VM

En este modelo, cada proceso tiene su espacio privado de memoria virtual, que comienza en 0 y se expande a 2 o 3.5 Gigabytes (dependiendo del CPU). Esto es logrado a través del MMU del procesador.

15. El Administrador de la Red (Qnet)

Introducción

Comunicándose directamente con el Microkernel, el Administrador de la Red mejora el intercambio de mensajes (IPC) propagando los mensajes eficazmente a las máquinas remotas. Además, el Administrador de la Red ofrece tres rasgos avanzados:

• Incrementa el throughput vía el equilibrio de carga
• la tolerancia a fallos vía conectividad redundante
• Puentes entre las redes de QNX

En pocas palabras, Qnet es una red basada en el envío de mensajes que le brinda acceso transparente a cualquier recurso del sistema. Qnet le permite construir aplicaciones eficientes y tolerantes a fallos que pueden ser escaladas fácilmente.

Qnet esta integrada en el corazón de las primitivas de manejo de procesos y envió de mensajes de QNX, haciendo que la intercomunicación de procesos local y a través de una red sea lo mismo. Usando Qnet, una red de nodos individuales se convierte en una supercomputadora virtual, donde cada nodo tiene acceso a todos los recursos del sistema.

El diseño único de Qnet le hace posible crear redes altamente escalables y tolerantes a fallo con soporte para balancear la carga.

Con Qnet, cualquier dispositivo en el sistema puede acceder cualquier recurso en forma transparente. Qnet extiende el mecanismo de envió de mensajes que forma el núcleo de la plataforma QNX. Utilizando Qnet, los mensajes son enviados de forma transparente de un nodo a otro, lo que hace posible acceder y utilizar recursos como por ejemplo sistemas de archivos, I/O, recursos de hardware, administradores de procesos y mas.

Un módulo independiente

El Administrador de la Red no tiene que ser construido en la imagen del sistema operativo. Puede ejecutarse y puede detenerse cuando quiera para proporcionar o quitar las capacidades de mensajería de red.

Cuando el Administrador de la Red empieza, se registra con el Administrador del Procesos y el Microkernel. Esto activa el código existente dentro de los dos que hace de interfase con el Administrador de la Red. Esto significa que mensajería de la red y la creación de procesos remotos no es sólo una capa agregada al sistema operativo.

Esta integración profunda al nivel más bajo le da transparencia a la red lo califica como un sistema operativo totalmente distribuido. Ya que las todas las aplicaciones acceden a los servicios vía mensajes, y que el Administrador de la Red permite a los mensajes fluir transparentemente en la red, los nodos de QNX trabajan juntos como una sola supercomputadora lógica.

Drivers de la red

Como el Administrador de Filesystem y el Administrador del Dispositivos, el Administrador de la Red no contiene ningún código hardware-específico. Esta funcionalidad es proporcionada por los Drivers de tarjeta de red. El Administrador de la Red puede soportar múltiples drivers de placas de red a la misma vez. Cada Driver soporta una sola tarjeta de red.

Las colas de memoria compartida proporcionan la interfase entre el Administrador de la Red y los drivers. El driver determina el protocolo apropiado para los medios de comunicación de la red.

El Driver es responsable de la packetización, la secuencia y retransmisión si la transmisión de datos garantizada y fiable es pedida por un nodo físico remoto. Este plan le permite a QNX soportar fácilmente nuevo hardware de red y protocolos, escribiendo o modificando solamente los Drivers red.

Equilibrio de carga y tolerancia a fallos

El throughput de la red es determinado por una combinación de la velocidad de la computadora y la velocidad de la red. Si su computadora puede proporcionar los datos más rápido que la red puede aceptarlo, entonces la red limitará su throughput.

El Administrador de la Red equilibrará automáticamente la carga escogiendo un driver de red apropiado.

Cuando nodos son conectados de a dos o más en la red, existe más de un camino a usar para la comunicación. Si una tarjeta en una red falla el Administrador de la Red re-dirigirá todos los datos automáticamente a través de otra red. Esto pasa automáticamente sin ningún tipo de intervención por parte del software de la aplicación, y resultados en la tolerancia a fallas de la red es totalmente transparente. Si se colocan cables para redes diferentes, usando rutas separadas, usted también se protegerá contra un corte de cable accidental.

Usted también puede construir sistemas en tándem, en que dos máquinas son conectadas por una red rápida para el funcionamiento normal y por una red más barata y más lenta que queda en espera. Si la primera red falla, la comunicación continuará, aunque se reduciría naturalmente el throughput.

Qnet permite alto rendimiento y tolerancia a fallos a través del soporte para múltiples enlaces entre nodos. Dependiendo en las necesidades de su sistema, usted puede elegir entre tres clases de servicios:

Balanceo de carga – El modulo administrador de red de Qnet decide que enlaces usar para el envío de paquetes dependiendo en la carga actual. Un paquete es encolado en el enlace que puede enviarlo mas rápidamente a través de la red. El resultado de esto es un mayor ancho de banda entre nodos y una menor degradación del servicio cuando el enlace falla. Cuando un enlace falla, paquetes periódicos de mantenimiento son enviados a ese enlace para detectar la recuperación.

Secuencial – el primer enlace es usado hasta que falla, luego el segundo link, y así sucesivamente. El usuario puede indicar el orden preferente de los enlaces.

Redundante – los paquetes son enviados a todos los links disponibles simultáneamente.

Arquitectura escalable

Con Qnet, es fácil crear redes altamente escalables. La misma aplicación puede correr en un procesador único o ser distribuida a través de múltiples procesadores. No se requiere recodificar. Y, ya que las aplicaciones no requieren código especifico para manejar la red, nuevas redes (Ethernet, serial, backplane) pueden ser introducidas, nuevamente, sin recodificar.

Puentes entre LANs

El Administrador de la Red permite a cualquier nodo actuar como un puente entre dos redes IEEE 802.

Ya que QNX usa el mismo formato de paquete y protocolo en todas las redes IEEE 802, usted puede crear los puentes entre Ethernet, Token Ring, y redes de FDDI. No pueden puentearse las redes de Arcnet.

Se soportan protocolos ARP, IP, ICMP, UDP, y protocolos de TCP también.

Redes TCP/IP

QNX implementa su protocolo propietario de red que está optimizado para proporcionar una rápida, e idéntica interfase entre computadoras basadas en QNX. Pero para comunicarse con sistemas que no utilizan QNX, utiliza el conjunto estándar de protocolos de red conocidos como TCP/IP.

Administrador de TCP/IP

El Administrador se deriva de la pila Berkeley BSD 4.3 que es la pila TCP/IP más común en Internet y se ha usado como la base para muchos sistemas.

NFS

El FileSystem de Red (NFS) es una aplicación TCP/IP que se ha implementado en sistemas DOS y Unix en su mayoría. NFS permite unir filesystems remotos (o porciones de ellos) en un espacio de nombres local. Los archivos en los sistemas remotos aparecen como la parte del filesystem local de QNX.

SMB

QNX también soporta los Bloques de Mensajes de Servidor (SMB) protocolo para compartir archivos, que son usados por varios servidores diferentes como Windows NT Windows 95, Windows para Workgroups, LAN Manager, y Samba. El filesystem de SMBfsys permite a un cliente de QNX acceder a los archivos remotos que residen en tales servidores transparentemente.

Internet Navegador Voyager

Con el navegador Voyager, la interfase y el motor son dos programas separadas. Esto crea una arquitectura cliente/servidor donde la interfase (cliente) dialoga con el motor del navegador (servidor) a través de la interfaz llamada PtWebClient.

Con una arquitectura como esta es muy fácil la personalización. Para modificar la interfaz del navegador, simplemente se modifica el PtWebClient.

Si usted necesita un navegador WEB para su sistema embebido y no desea desperdiciar tiempo y dinero en construir uno, el navegador Voyager es para usted. Esta completamente equipado y es altamente modular, puedo correr en modo completo o compacto. Puede escalarlo desde un navegador básico con un manejo de memoria optimizado hasta incluir soporte para múltiples idiomas, un discador, etc…

Servidor WEB

Controle remotamente su fotocopiadora, reciba estadísticas de virtualmente cualquier dispositivo desde su navegador con el servidor WEB. Suficientemente pequeño para una impresora láser, y robusto para un robot de fabrica, este servidor le permite incluso a sistemas embebidos sin disco generar paginas dinámicas en tiempo real.

FLEETTM – la Gestión de redes Alto rendimiento para QNX

FLEET es una característica única de QNX que crea un solo conjunto homogéneo de recursos que se pueden acceder en forma transparente, desde cualquier lugar de la red. FLEET es un protocolo de red ultra liviano y de alta velocidad. Hace que todas las computadoras conectadas se vean como una sola supercomputadora lógica. Porque FLEET se construye sobre la arquitectura del pasaje de mensaje del QNX OS, ofrece lo último en flexibilidad. FLEET ofrece:

• Trabajo en red con total tolerancia a fallos
• Carga balanceada del trabajo
• Performance eficiente
• Arquitectura extensible
• Procesamiento distribuido transparente

Trabajo en red con total tolerancia a fallos

Si un cable o tarjeta de red en una red falla, FLEET automáticamente rutea los datos a través de otra red. Esto pasa en la red, sin involucrar software de aplicación, dándole automática tolerancia a falla de la red.

Carga balanceada del trabajo

El throughput de la red está normalmente limitado por la velocidad de su computadora y hardware de la red. Con FLEET, pueden transmitirse datos simultáneamente sobre múltiples redes, permitiéndole doblar, triplicar, o incluso cuadruplicar el ancho de banda de la red y throughput poniendo múltiples tarjetas de red en cada computadora y conectándolas con cables separados. Usted puede mezclar tipos diferentes de tarjetas de red incluso (ej. Ethernet, FDDI) en la misma máquina.

Performance eficiente

Drivers de red FLEET son construidos para hacer la mayoría del hardware de gestión de redes. Por ejemplo, al enviar bloques grandes de datos en una red de Ethernet de un proceso a otro, usted obtendrá:

Tipo de red No. de procesos del cliente Throughput

10 Mbit Ethernet 1 1.1 Mbytes/sec

100 Mbit Ethernet 1 7.5 Mbytes/sec

Arquitectura extensible

Gracias a FLEET, una red de QNX le da excelente flexibilidad. Los procesos de una red de computadoras son arquitectónicamente distintos para el OS, permitiéndole empezar y detener un nodo conectado en cualquier momento. Esto significa que usted puede agregar nodos a su red o puede quitarlos dinámicamente sin reconfigurar su sistema. Y, gracias al puenteo automático de red, usted puede agregar redes físicas diferentes también a su LAN.

Procesamiento distribuido transparente

Los procesos de red de FLEET están integrados en el corazón del pasaje de mensajes y primitives de administración de procesos, haciendo el ancho de red IPC y local uno y el mismo. Puesto que IPC es transparente, una red de PCs individual aparece como una sola. ¿El resultado? Usted nunca necesita modificar sus aplicaciones para comunicar a tavés de la red.

16. Photon MicroGUI

Introducción

Muchas sistemas embebidos requieren una interfaz de usuario para interactuar con las aplicaciones. Para simplificar las complejas interfaces de usuario, un sistemas gráficos de ventana es una elección natural. Sin embargo, los sistemas de ventanas en las PC de escritorio simplemente requieren demasiados recursos para ser practicas en un sistema embebido que tiene limitaciones de memoria y costo. A continuación se detalla la arquitectura única de Photon microGUI, un sistema de ventana escalable que corre con menos de 500K de memoria y sin embargo entrega toda la funcionalidad esperada de un sistema de ventanas e introduciendo muchas opciones de conectividad.

Photon microGUI ha sido diseñado para entregar un sistema grafico de ventanas a ambientes con restricciones de recursos. A través de su única arquitectura, también provee:

Opciones de escalabilidad – Photon puede ser escalado en un sistema grafico completo para escritorio. Photon puede ser integrado con sistemas de ventanas heterogéneos.

Tolerancia a fallos – si una parte del sistema de ventanas falla, ese componente puede ser reiniciado "en el vuelo" sin colgar el sistema entero.

Un microkernel grafico Siguiendo la arquitectura del microkernel de QNX, y teniendo este una intercomunicación de proceso muy eficiente, el microkernel grafico se estructura como un proceso con un equipo de procesos adicionales cooperando con este, comunicándose vía IPC.

El microkernel de photon corre como un pequeño proceso (45K de código), implementando solo unas primitivas fundamentales que procesos externos usan para construir funcionalidades de mas alto nivel. Irónicamente, para el microkernel la palabra "ventana" no existe como así tampoco puede dibujar nada ni administrar mouse, teclado, etc.

En primero momento esto puede parecer similar a construir un sistema grafico alrededor del paradigma cliente/servidor ya utilizado en X Window. La arquitectura de Photon se diferencia restringiendo la funcionalidad implementada en el microkernel grafico ( o servidor ) y distribuyendo la mayor parte de la funcionalidad del GUI entre los procesos cooperadores.

Estos procesos, como por ejemplo el administrador de recursos del GUI y el administrador de ventanas pueden ser agregados dinámicamente al sistema corriendo sin tener que reiniciar.

(Para ver el gráfico faltante haga click en el menú superior "Bajar Trabajo")

Photon de adapta a cualquier ambiente: Internet. Electrónica. Telefonía. Instrumentación medica. Automatización industrial. PDAs . Puntos de venta. Y mas!

El espacio de evento de Photon

El "espacio de eventos" administrado por Photon puede ser visualizados como un espacio vacío con una región base al fondo. El usuario final puede ser imaginado como mirando a través de este espacio de eventos. Las aplicaciones colocan regiones en el espacio tridimensional entre la región base y el usuario final. Usan esas regiones para generar y aceptar varios tipos de eventos entre este espacio.

Los procesos que proveen servicios de driver colocan regiones adelante del espacio de eventos.

(Para ver el gráfico faltante haga click en el menú superior "Bajar Trabajo")

Se puede pensar que estos eventos viajen a través de este espacio como fotones.

La interacción entre eventos y regiones es la base de las entradas y salidas en Photon. Los eventos de mouse y teclado viajan desde el usuario hacia la región base. Los eventos de dibujo originados por regiones viajen hacia el usuario.

Drivers gráficos

Los drivers gráficos son implementados como procesos que están en el frente del espacio de eventos. Una región grafica es sensible a los eventos de dibujo provenientes del espacio de eventos. Cuando los eventos de dibujo intersectan la región, estos son recibidos por el proceso de driver grafico. De hecho, esta región puede ser imaginada como cubierta por fósforo, el cual es iluminado por el impacto de los fotones.

Múltiples drivers gráficos

Puesto que los drivers gráficos simplemente colocan una región en el espacio de eventos, y ya que esta región es un rectángulo que será interceptado por eventos de dibujo, naturalmente se puede utilizar drivers gráficos múltiples para múltiples controladoras graficas, todas con su región de dibujo presente es el mismo espacio de eventos.

Estas múltiples regiones puede ser puestas adyacentes una de la otra o solapadas de diversas maneras. Ya que photon hereda la transparencia de red de QNX, las aplicaciones o drivers pueden corren en cualquier nodo de la red, permitiendo drivers gráficos adicionales extender el espacio grafico de Photon al espacio físico de varios computadoras en red. Al tener este esquema, los eventos gráficos pueden ser replicados en múltiples pantallas.

Muchas aplicaciones interesantes se hacen posibles con esta capacidad. Por ejemplo, un operador de una fabrica con una computadora inalámbrica de mano puede caminar hacia una estación de trabajo y arrastrar una ventana de la planta de control en su computadora de mano y luego interactuar con el sistema de control.

Control remoto Con photon, la conectividad esta incluida. Realmente no hay diferencia en que sus clientes estén en la misma ciudad o en el otro lado del mundo. Usted puede monitorear y brindarles soporte fácilmente. De hecho, usted puede ver e interactuar con cualquier aplicación Photon en cualquier momento y en cualquier lugar, usando Internet, TCP/IP o módems.

JumpGate Connectivity Con JumpGate no necesita escribir una pregunta acerca de una aplicación y enviársela por mail a un colega. Con Photon, se puede enviar la interfaz de la aplicación entera y además, su colega puede interactuar con la aplicación y enviársela nuevamente.

Palabras clave: Sistema Operativo de tiempo real, Tiempo real, sistema operativo, sistemas embebidos, Microkernel, INVAP, SAC-C, Kernel, Multitarea, SCHEDULER, Round Robin, FIFO, QNX

Categoría: Sistemas operativos

Resumen: Aquí un aporte desde Argentina, para la categoría sistemas operativos, se trata de el SO QNX 4.25, que es perfecto para sistemas de tiempo real y para sistemas embebidos, es un trabajo de 88 página bastante completito

Trabajo enviado y realizado por: Mauro Strione

25 Años Argentino – Soltero Analista Universitario de sistemas Estudiante de ingeniería en informática.