DNIX

Dataindustrier AB (traducción literal: sociedad anónima de la industria informática) fue fundada en 1970 por Lars Karlsson como fabricante de ordenadores de placa única en Sundsvall , Suecia , produciendo un ordenador basado en Zilog Z80 llamado Data Board 4680. En 1978, DIAB comenzó a trabajar con la compañía de televisión sueca Luxor AB para producir las series de ordenadores domésticos y de oficina ABC 80 y ABC 800 .

En 1983, DIAB desarrolló de forma independiente la primera máquina compatible con Unix , la DIAB DS90, basada en la CPU Motorola 68000. Aquí apareció D-NIX, basado en una licencia de UNIX System V de AT&T Corporation . Sin embargo, DIAB era una empresa de sistemas de control industrial (automatización) y necesitaba un sistema operativo en tiempo real , por lo que reemplazó el núcleo UNIX proporcionado por AT&T con su propia variante en tiempo real, desarrollada internamente y compatible. Este núcleo se inspiró en un núcleo Z80 llamado OS.8 , creado para la división Monroe Systems de Litton Industries . ^{[ 1 ] [ 2 ]}

Con el tiempo, la empresa también reemplazó varias de las herramientas estándar del espacio de usuario de UNIX con sus propias implementaciones, hasta el punto de que ningún código derivaba de UNIX, y sus máquinas podían implementarse independientemente de cualquier licencia de AT&T UNIX. Dos años más tarde y en cooperación con Luxor, se desarrolló una computadora llamada ABC 1600 para el mercado de oficinas, mientras que, paralelamente, DIAB continuó produciendo versiones mejoradas de la computadora DS90 utilizando versiones más recientes de las CPU de Motorola, como Motorola 68010 , 68020 , 68030 y finalmente 68040. En 1990, DIAB fue adquirida por Groupe Bull , que continuó produciendo y dando soporte a las máquinas DS bajo la marca DIAB , con nombres como DIAB 2320 , DIAB 2340 , etc., que aún ejecutaban la versión de DNIX de DIAB. ^{[ 3 ]}

ISC Systems Corporation (ISC) adquirió los derechos de uso de DNIX a finales de la década de 1980 para su uso en su línea de computadoras bancarias basadas en Motorola 68k . (ISC fue comprada posteriormente por Olivetti , y a su vez revendida a Wang , que luego fue comprada por Getronics . Esta entidad corporativa, más comúnmente conocida como 'ISC', ha respondido a una desconcertante variedad de nombres a lo largo de los años). Esta rama de código era la versión compatible con SVR2 , y recibió una extensa modificación y desarrollo por parte de ellos. Las características notables de este sistema operativo fueron su soporte para paginación bajo demanda , estaciones de trabajo sin disco , multiprocesamiento , entrada/salida (E/S) asíncrona , la capacidad de montar procesos (manejadores) en directorios en el sistema de archivos y paso de mensajes . Su soporte en tiempo real consistía principalmente en colas internas controladas por eventos en lugar de mecanismos de búsqueda de listas (sin 'tormenta de truenos' ^{[ 4 ]} ), prioridades de procesos estáticas en dos clases (ejecución completa y segmentación temporal), soporte para archivos contiguos (para evitar la fragmentación de recursos críticos) y bloqueo de memoria. La calidad de la implementación de eventos asíncronos ortogonales aún no ha sido igualada en los sistemas operativos comerciales actuales, aunque algunos se acercan. (El concepto que aún no se ha adoptado es que el punto de serialización síncrono de toda la actividad asíncrona también podría ser asíncrono, ad infinitum. DNIX manejó esto con aplomo). La facilidad de E/S asíncrona evitó la necesidad de la selección de sockets de Berkeley o el mecanismo de sondeo STREAMS de SVR4 , aunque había una biblioteca de emulación de sockets que conservaba la semántica de sockets para la compatibilidad con versiones anteriores. Otra característica de DNIX fue que ninguna de las utilidades estándar (como ps, un infractor frecuente) rebuscaban en la memoria del núcleo para hacer su trabajo. En su lugar, se usaban llamadas al sistema, y ​​esto significaba que la arquitectura interna del núcleo era libre de cambiar según fuera necesario. El concepto de manejador permitía que las pilas de protocolos de red estuvieran fuera del núcleo, lo que facilitó enormemente el desarrollo y mejoró la fiabilidad general, aunque a costa del rendimiento. También permitía que los sistemas de archivos externos fueran procesos de nivel de usuario, de nuevo para mejorar la fiabilidad. El sistema de archivos principal, aunque podría haber sido (y una vez fue) un proceso externo, se integró en el núcleo por razones de rendimiento. Si no fuera por esto, DNIX bien podría haberse considerado un micronúcleo , aunque no se desarrolló formalmente como tal. Los manejadores podían aparecer como cualquier tipo de archivo, estructura de directorio o dispositivo Unix 'nativo', y las solicitudes de E/S de archivos que el manejador no podía procesar podían pasarse a otros manejadores, incluido el subyacente en el que estaba montado el manejador. Las conexiones de manejador también podían existir y pasarse independientemente del sistema de archivos, de forma muy parecida a una tubería . Una de las consecuencias de esto es que se podrían emular dispositivos tipo terminal de texto (TTY) sin necesidad de una función de pseudoterminal basada en el kernel .

Un ejemplo de cómo un manejador resultó útil se dio en la compatibilidad de ISC con estaciones de trabajo sin disco, donde un error en la implementación provocaba que el uso de tuberías con nombre en la estación de trabajo pudiera generar bloqueos de recursos no deseados en el servidor de archivos. Se creó un manejador en la estación de trabajo para controlar los accesos a las tuberías con nombre afectadas hasta que se pudieran desarrollar las correcciones necesarias en el kernel. Este manejador requirió aproximadamente 5 kilobytes de código para su implementación, lo que demuestra que un manejador complejo no tiene por qué ser extenso.

ISC también obtuvo el derecho a fabricar las máquinas DS90-10 y DS90-20 de DIAB como sus servidores de archivos. Sin embargo, las DS90-20 multiprocesador eran demasiado caras para el mercado objetivo, por lo que ISC diseñó sus propios servidores y adaptó DNIX a ellos. ISC diseñó sus propias estaciones de trabajo sin disco con interfaz gráfica de usuario para usar con estos servidores de archivos y volvió a adaptar DNIX. (Aunque ISC usó estaciones de trabajo Daisy con Daisy DNIX para diseñar las máquinas que ejecutarían el DNIX de DIAB, hubo una confusión mínima interna, ya que el personal de diseño y maquetación rara vez hablaba con el personal de software. ¡Además, el personal de diseño de hardware no usaba ninguno de los dos sistemas! La broma recurrente era algo así como: "En ISC construimos computadoras , no las usamos "). La compatibilidad con E/S asíncronas de DNIX permitió una programación sencilla basada en eventos en las estaciones de trabajo, que funcionaron bien a pesar de tener recursos relativamente limitados. (La estación de trabajo sin disco con interfaz gráfica tenía un procesador 68010  de 7 MHz y era utilizable con solo 512 KB de memoria, de los cuales el núcleo consumía aproximadamente la mitad. La mayoría de las estaciones de trabajo tenían 1 MB de memoria, aunque posteriormente hubo versiones de 2 MB y 4 MB, junto con procesadores de 10 MHz). Una instalación completa podía consistir en un servidor ( 68020 de 16 MHz , 8 MB de RAM y un disco duro de 200 MB) y hasta 64 estaciones de trabajo. Aunque lento para arrancar, tal conjunto funcionaría de manera aceptable en una aplicación de cajero bancario . Además de la eficiencia inherente de DNIX, el compilador DIAB C asociado fue clave para un alto rendimiento. Generaba código particularmente bueno para el 68010 , especialmente después de que ISC lo terminara. (ISC también lo redirigió al coprocesador gráfico Texas Instruments TMS34010 utilizado en su última estación de trabajo). El compilador DIAB C se utilizó, por supuesto, para construir DNIX, lo que fue uno de los factores que contribuyeron a su eficiencia, y todavía está disponible, de alguna forma, a través de Wind River Systems .  

Estos sistemas siguen en uso a fecha de 2006, en antiguas sucursales del Seattle-First National Bank, ahora conocidas como Bank of America . Es posible que existan, y probablemente existan, otros clientes de ISC que aún utilicen DNIX de alguna forma. A través de ISC, DNIX tuvo una presencia considerable en Centroamérica y Sudamérica .

Además de la dnix(2)llamada nativa, estaba disponible un conjunto completo de llamadas de interfaz libcopen(2) 'estándar'. , close(2), read(2), write(2), etc. Además de ser útiles para la retrocompatibilidad, estas se implementaron de manera binariamente compatible con la computadora NCR Tower , de modo que los binarios compilados para ella se ejecutarían sin cambios bajo DNIX. El núcleo DNIX tenía dos despachadores de interrupciones internamente, uno para el método DNIX y otro para el método Unix. La elección del despachador dependía del programador, y era aceptable usar ambos indistintamente. Semánticamente eran idénticos dondequiera que la funcionalidad se superpusiera. (En estas máquinas, la instrucción 68000trap #0 se usaba para las unix(2)llamadas, y la trap #4instrucción para dnix(2). Los dos manejadores de interrupciones eran muy similares, aunque la unix(2)llamada [generalmente oculta] mantenía el código de la función en el registro D0 del procesador, mientras que dnix(2)lo mantenía en la pila con el resto de los parámetros).

DNIX 5.2 no tenía pilas de protocolos de red internas (excepto la pila de protocolos Ethernet basada en X.25 añadida por ISC para su paquete de soporte de estaciones de trabajo sin disco); toda la comunicación en red se realizaba mediante lectura y escritura en manejadores. Por lo tanto, no existía un mecanismo de sockets , pero sí uno que utilizaba E/S asíncrona para comunicarse con el manejador TCP/IP. El programa de red típico derivado de Berkeley podía compilarse y ejecutarse sin modificaciones (salvo los problemas habituales de portabilidad a Unix ), aunque podría no ser tan eficiente como un programa equivalente que utilizara E/S asíncrona nativa.libsocket(3)

Para comprender mejor la utilidad de los manejadores, cabe mencionar que en ISC existían manejadores para:

• sistemas de archivos extranjeros
  • GORDO
  • CD-ROM / ISO9660
  • archivos de imagen de disco
  • Disco RAM (para usar con discos de arranque protegidos contra escritura)
• protocolos de red
  • DNET (esencialmente X.25 sobre Ethernet , con capacidad de multidifusión )
  • X.25
  • TCP/IP
  • DIC LAT
  • AppleTalk
• sistemas de archivos remotos
  • Ruta /net/machine/path/from/its/root de DNET...
  • NFS
• inicio de sesión remoto
  • ncu (DNET)
  • telnet
  • rlogin
  • wcu (GUI de DNET)
  • Almohadilla X.25
  • DIC LAT
• ejecución remota
  • rx (DNET)
  • remsh
  • rexec
• extensión del sistema
  • windowman (GUI)
  • vterm (similar a xterm )
  • Impresora de documentos (libretas de ahorro)
  • dmap (análogo de ruptime)
  • windowmac ​​(puerta de enlace con interfaz gráfica para Macintosh)
• parches del sistema
  • manipulador de tuberías con nombre

Cuando el desarrollo de DNIX en ISC cesó efectivamente en 1997, varias características planificadas del sistema operativo quedaron sin implementar:

• Objetos compartidos : Existían dos bibliotecas de carga dinámica, un encriptador para DNET y la biblioteca de procesamiento de imágenes de la interfaz gráfica de usuario, pero esta funcionalidad nunca se generalizó. Las máquinas de ISC se caracterizaban por una escasez general de espacio de direcciones virtuales , por lo que no habría sido posible un uso extensivo de entidades mapeadas en memoria.
• Procesos ligeros : el kernel ya contaba con múltiples hilos que compartían un único contexto MMU, por lo que extender esto a los procesos de usuario debería haber sido sencillo. Las implicaciones de la API habrían sido la parte más difícil.
• Listas de control de acceso (ACL): Su implementación es muy sencilla utilizando un controlador de ACL montado sobre el sistema de archivos estándar.
• Múltiples particiones de intercambio: DNIX ya utilizaba espacio libre en el volumen seleccionado para el intercambio; habría sido fácil proporcionarle una lista de volúmenes para probar uno por uno, posiblemente con límites de espacio asociados para evitar que consumiera todo el espacio libre en un volumen antes de pasar al siguiente.
• Depuración remota del kernel mediante gdb : existían todos los elementos necesarios para hacerlo, ya fuera a través del puerto serie habitual o mediante Ethernet utilizando el software de enlace X.25 integrado en el kernel, pero nunca se ensamblaron.
• Soporte para el 68030 : los prototipos de ISC nunca se completaron. Se construyeron dos tarjetas de expansión para procesadores, pero nunca se utilizaron como algo más que versiones más rápidas del 68020. No eran fiables ni tan rápidas como podrían haber sido debido a la necesidad de encajar en un zócalo del 68020. La MMU de conmutación de contexto rápida de ISC se dejaría desactivada (y se eliminaría por completo en las unidades de producción propuestas), y en su lugar se utilizaría la integrada del 68030, mediante una derivación del código de la MMU del DS90-20. Si bien la MMU de ISC era muy eficiente y admitía la conmutación instantánea entre 32 procesos residentes, su capacidad de direccionamiento era muy limitada. La MMU del 68030 habría permitido mucho más de 8 MB de espacio virtual en un proceso, que era el límite de la MMU de ISC. Si bien esta MMU sería más lenta, la mayor velocidad general del 68030 debería haberlo compensado con creces, por lo que se esperaba que una máquina 68030 fuera en todos los sentidos más rápida y admitiera procesos mucho más grandes.