stringtranslate.com

Tiempo real multiambiente

Multi-Environment Real-Time ( MERT ), posteriormente rebautizado como UNIX Real-Time ( UNIX-RT ), [3] es un sistema operativo híbrido de tiempo compartido y tiempo real desarrollado en la década de 1970 en Bell Labs para su uso en minicomputadoras integradas ( especialmente PDP-11 ). Una versión denominada Duplex Multi Environment Real Time ( DMERT ) fue el sistema operativo de la minicomputadora de conmutación telefónica AT&T 3B20D , diseñada para alta disponibilidad ; [4] [5] [6] DMERT pasó a llamarse posteriormente Unix RTR (Real-Time Reliable). [6]

MERT, una generalización del sistema operativo de tiempo compartido Unix de Bell Labs , [7] presentaba un núcleo modular rediseñado que era capaz de ejecutar programas Unix y procesos informáticos privilegiados en tiempo real . Las estructuras de datos de estos procesos se aislaron de otros procesos y el paso de mensajes fue la forma preferida de comunicación entre procesos (IPC), aunque también se implementó la memoria compartida . MERT también tenía un sistema de archivos personalizado con soporte especial para archivos grandes, contiguos y de tamaño estático, como los que se utilizan en aplicaciones de bases de datos en tiempo real . El diseño de MERT fue influenciado por THE de Dijkstra, Monitor de Hansen y CP-67 de IBM . [2]

El sistema operativo MERT tenía un diseño de cuatro capas, en orden decreciente de protección : [2]

El supervisor estándar era MERT/UNIX, un emulador de Unix con una interfaz de llamada al sistema extendida y un shell que permitía el uso de mecanismos IPC personalizados de MERT, aunque también existía un emulador RSX-11 . [2]

Procesos kernel y no kernel

Una característica interesante que introdujo DMERT – UNIX-RTR fue la noción de procesos del kernel . Esto está relacionado con sus raíces en la arquitectura microkernelish . Como soporte, hay un comando separado ( /bin/kpkill) en lugar de ( /bin/kill), que se utiliza para enviar señales a los procesos del kernel. Es probable que también haya dos llamadas al sistema diferentes ( kill(2)y kpkill(2), la primera para finalizar un proceso de usuario y la segunda para finalizar un proceso de kernel). Se desconoce qué parte del mecanismo de señalización normal del espacio de usuario existe en /bin/kpkill, suponiendo que haya una llamada al sistema para ello, no se sabe si se pueden enviar varias señales o simplemente enviar una. También se desconoce si el proceso del núcleo tiene alguna forma de captar las señales que se le envían. Puede ser que los desarrolladores de UNIX-RTR implementaran una interfaz de programación de aplicaciones (API) de señales y mensajes completa para los procesos del kernel.

Bits del sistema de archivos

Si uno tiene root en un sistema UNIX-RTR, seguramente pronto descubrirá que su ls -lresultado es un poco diferente de lo esperado. Es decir, hay dos bits completamente nuevos en este drwxr-xr-xcampo. Ambos tienen lugar en la primera columna y son C(contiguos) y x( extensiones ). Ambos tienen que ver con datos contiguos, sin embargo, uno puede tener que ver con inodos y el otro con no metadatos.

Ejemplo ls -l:

 drwxr-xr-x  root 64 domingo 4 de diciembre de 2003 /cft xrwxr-xr-x root 64 lunes 11 de diciembre de 2013 /no5text Crwxr-xr-x root 256 martes 12 de diciembre de 2014 /no5data                      

Emulador Lucent y VCDX

AT&T, luego Lucent y ahora Alcatel-Lucent , son los proveedores del paquete ATT3bem basado en SPARC y OEM de Solaris (que reside en Solaris SPARC en /opt/ATT3bem). Este es un emulador 3B21D completo (conocido como 3B21E, el sistema detrás de Very Compact Digital eXchange, o VCDX) que está destinado a proporcionar un entorno de producción para la parte del módulo administrativo (AM) del conmutador 5ESS . Hay partes del 5ESS que no forman parte en absoluto de la microcomputadora 3B21D: SM y CM. En el emulador, la estación de trabajo se denomina 'AW' (estación de trabajo administrativa). El emulador se instala con Solaris 2.6/SPARC y también viene con Solstice X.25 9.1 (SUNWconn), anteriormente conocido como SunLink X.25. La razón para empaquetar la pila X.25 con el emulador 3B21D es porque Bell System, las compañías operativas regionales de Bell y los ILEC todavía usan redes X.25 para sus sistemas más críticos (los conmutadores telefónicos pueden vivir en X.25 o Datakit VCS). II, una red similar desarrollada en Bell Labs, pero no tienen pilas TCP/IP).

El emulador de AT&T/Alcatel-Lucent no es un programa fácil de hacer funcionar correctamente, incluso si uno logra tener una imagen de un archivo de salida 'dd' del disco duro 5ESS que funciona. Primero, hay bastantes errores que el usuario debe solucionar durante el proceso de instalación. Una vez hecho esto, hay un archivo de configuración que conecta los periféricos con los periféricos emulados. Pero hay escasa documentación en el CD que describa esto. El nombre de este archivo es em_devmap para SS5 y em_devmap.ultra para Ultra60.

Además, uno de los errores mencionados en el proceso de instalación es un script roto para fdisk y crear imágenes de discos duros correctamente: ciertas cosas deben escribirse en ciertas compensaciones, porque el proceso /opt/ATT3bem/bin/3bem espera, o parece necesita, estas ubicaciones codificadas.

El emulador se ejecuta en SPARCstation-5 y UltraSPARC-60. Es probable que el 3B21D se emule más rápido en un SPARC moderno que el procesador de una microcomputadora 3B21D, medido en MIPS. Lo más difícil de tener el emulador es adquirir una imagen de disco duro DMERT/UNIX-RTR para ejecutarlo. El sistema operativo del 5ESS está restringido a unas pocas personas, empleados y clientes del proveedor, que trabajan en él o escriben el código. Tener una imagen de un sistema en ejecución, que se puede obtener en eBay, extraer de un 3B21D en funcionamiento y convertirla en un archivo o colocar en un Ultra60 o SPARCstation-5, proporciona los recursos para intentar ejecutar el sistema UNIX-RTR.

La salida uname -a del shell Bourne que ejecuta UNIX-RTR (confiable en tiempo real) es:

# uname  -a  <3B21D> <3B21D>

Aunque en los sistemas 3B20D imprimirá 20 en lugar de 21, aunque los 3B20D son raros, hoy en día la mayoría de los 5ESS que no son VCDX son hardware 3B21D, no 3B20D (aunque ejecutarán bien el software). El 3B20D usa el procesador WE32000 mientras que el 21 usa el WE32100. También puede haber otras diferencias. Una cosa inusual sobre el procesador es la dirección en la que crece la pila: hacia arriba.

Página de manual para falloc (que puede ser responsable de la asignación de espacio de archivos contiguos o eXtent):

 FALLOC(1) 5ESS UNIX FALLOC(1) NOMBRE falloc - asigna un archivo contiguo SINOPSIS tamaño del nombre de archivo faloc DESCRIPCIÓN Se asigna un archivo contiguo del nombre de archivo especificado a ser de bloques de 'tamaño' (512 bytes). DIAGNÓSTICO El comando se queja de que no se puede buscar en un directorio necesario, el directorio final no se puede escribir, el archivo ya existe o no hay suficiente espacio para el archivo.


UNIX-RTR incluye un comando de intercambio de archivos atómico (atomsw, página del manual a continuación):

 ÁTOMOSW(1) 5ESS UNIX ÁTOMOSW(1) NOMBRE atomsw - Archivos de interruptor atómico SINOPSIS átomosw archivo1 archivo2 DESCRIPCIÓN Conmutador atómico de dos archivos. Los contenidos, permisos y los propietarios de dos archivos se cambian en una sola operación. En En caso de fallo del sistema durante la ejecución de este comando, file2 tendrá su contenido original, permisos y propietario, o tendrá el contenido, permisos y dueño. Por tanto, el archivo2 se considera valioso. El archivo 1 puede ser truncado en caso de fallo del sistema. RESTRICCIONES Ambos archivos deben existir. Ambos archivos deben residir en el mismo sistema de archivos. Ninguno de los archivos puede ser un "dispositivo especial" (por por ejemplo, un puerto TTY). Para ingresar este comando desde el shell craft, cambiando de archivo "/tmp/abc" con el archivo "/tmp/xyz", ingrese para MML: EXC:ENVIR:UPROC,FN="/bin/atomsw",ARGS="/tmp/abc"-"/tmp/xyz"; Para PDS ingrese: EXC:ENVIR:UPROC,FN"/bin/atomsw",ARGS("/tmp/abc","/tmp/xyz")! NOTA El archivo 1 puede perderse durante una falla del sistema. ARCHIVOS /bin/átomosw

Referencias

  1. ^ abc Bayer, DL; Lycklama, H. (1975). MERT: un sistema operativo multientorno en tiempo real. Quinto Simposio ACM sobre principios de sistemas operativos. Austin, Texas. doi : 10.1145/800213.806519 . Consultado el 18 de agosto de 2008 .
  2. ^ abcd Lycklama, H.; Bayer, DL (julio-agosto de 1978). "El sistema operativo MERT". Revista técnica del sistema Bell . 57 (6): 2049–2086. doi :10.1002/j.1538-7305.1978.tb02142.x. S2CID  8711402.
  3. ^ Bodenstab, DE; Houghton, TF; Kelleman, KA; Ronkin, G.; Schan, EP (1984). "Experiencias de portabilidad del sistema operativo UNIX". Revista técnica de AT&T Bell Laboratories . 63 (8): 1769-1790. doi :10.1002/j.1538-7305.1984.tb00064.x. S2CID  35326182.
  4. ^ Kane, JR; Anderson, RE; McCabe, PS (enero de 1983). "El procesador 3B20D y el sistema operativo DMERT: descripción general, arquitectura y rendimiento de DMERT". Revista técnica del sistema Bell . 62 (1): 291–301. doi :10.1002/j.1538-7305.1983.tb04396.x. S2CID  31828139.
  5. ^ Grzelakowski, YO; Campbell, JH; Dubman, MR (enero de 1983). "El procesador 3B20D y el sistema operativo DMERT: sistema operativo DMERT". Revista técnica del sistema Bell . 62 (1): 303–322. doi :10.1002/j.1538-7305.1983.tb04397.x. S2CID  12901173.
  6. ^ ab Wallace, John J.; Barnes, Walter W. (agosto de 1984). "Diseño para una disponibilidad ultraalta: el sistema operativo Unix RTR" (PDF) . Computadora IEEE . 17 (8). IEEE : 31–39. doi :10.1109/MC.1984.1659215. S2CID  17689432.
  7. ^ Ritchie, Dennis M. (1977). El sistema de tiempo compartido Unix: una retrospectiva. Décima Conferencia Internacional de Hawái sobre Ciencias de Sistemas. Archivado desde el original el 5 de febrero de 2015.