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.