DNIX (ortografía original: D-Nix ) es un sistema operativo en tiempo real similar a Unix descontinuado de la compañía sueca Dataindustrier AB (DIAB). También se desarrolló una versión llamada ABCenix para la computadora ABC 1600 de Luxor. ( Daisy Systems también tenía algo llamado Daisy DNIX en algunas de sus estaciones de trabajo CAD . No estaba relacionado con el producto DIAB).
Desarrollador | Dataindustrier AB |
---|---|
Familia OS | Tipo Unix |
Estado de trabajo | Histórico |
Modelo fuente | Fuente cerrada |
Último lanzamiento | 5.4 |
Licencia | Propiedad |
Historia
Inicio en DIAB en Suecia
Dataindustrier AB (traducción literal: empresa accionaria de industrias informáticas) fue fundada en 1970 por Lars Karlsson como un fabricante de computadoras de placa única en Sundsvall , Suecia , que producía una computadora basada en Zilog Z80 llamada Data Board 4680 . [ aclaración necesaria ] En 1978, DIAB comenzó a trabajar con la compañía de televisión sueca Luxor AB para producir las series de computadoras para el hogar y la oficina ABC 80 y ABC 800 .
En 1983, DIAB desarrolló de forma independiente la primera máquina compatible con UNIX , DIAB DS90, basada en la CPU Motorola 68000 . Aquí hizo su aparición D-NIX, basado en una licencia UNIX System V de AT&T . Sin embargo, DIAB era una empresa de automatización industrial y necesitaba un sistema operativo en tiempo real , por lo que la empresa reemplazó el kernel UNIX suministrado por AT&T por su propia variante en tiempo real desarrollada internamente, pero compatible. Este kernel era originalmente un kernel Z80 llamado OS8 . [1]
Con el tiempo, la compañía también reemplazó varias de las herramientas de espacio de usuario estándar de UNIX con sus propias implementaciones, hasta el punto en que no se derivó ningún código de UNIX y sus máquinas se pudieron implementar independientemente de cualquier licencia UNIX de AT&T. 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 en paralelo, DIAB continúa produciendo versiones mejoradas de la computadora DS90 utilizando versiones más nuevas de las CPU de Motorola como Motorola 68010 , 68020 , 68030. y finalmente 68040 . En 1990, DIAB fue adquirido por Groupe Bull, quien 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 ejecutan la versión DIAB de DNIX. [2]
Derivado en ISC Systems Corporation
ISC Systems Corporation (ISC) compró el derecho de usar DNIX a fines de la década de 1980 para usarlo en su línea de computadoras bancarias Motorola 68k . (ISC fue comprada más tarde por Olivetti y, a su vez, se vendió a Wang , que luego fue comprada por Getronics . Esta entidad corporativa, a la que se hace referencia más a menudo como 'ISC', ha respondido a una desconcertante variedad de nombres a lo largo de los años). La rama de código era la versión compatible con SVR2 y recibió una amplia modificación y desarrollo de su mano. Las características notables de este sistema operativo fueron su soporte de paginación por demanda , estaciones de trabajo sin disco , multiprocesamiento , E / S asíncronas , la capacidad de montar procesos (controladores) en directorios en el sistema de archivos y paso de mensajes . Su soporte en tiempo real consistió principalmente en colas internas controladas por eventos en lugar de mecanismos de búsqueda de listas (sin 'manada atronadora' [3] ), prioridades de proceso estáticas en dos clases (ejecutar hasta el final y dividido en el tiempo), soporte para archivos contiguos (para evitar fragmentación de recursos críticos) y bloqueo de memoria. La calidad de la implementación de eventos asíncronos ortogonales aún no se ha igualado en los sistemas operativos comerciales actuales, aunque algunos se acercan a ella. (El concepto que aún no se ha adoptado es que el punto de referencia sincrónico de toda la actividad asincrónica en sí podría ser asincrónico, ad infinitum. DNIX manejó esto con aplomo). La instalación de E / S asincrónica obvió la necesidad de Berkeley sockets select o SVR4 El mecanismo de encuesta STREAMS , aunque había una biblioteca de emulación de socket que conservaba la semántica del socket para compatibilidad con versiones anteriores. Otra característica de DNIX era que ninguna de las utilidades estándar (como ps , un delincuente frecuente) hurgaba en la memoria del kernel para hacer su trabajo. En su lugar, se utilizaron llamadas al sistema, y esto significó que la arquitectura interna del kernel podía cambiar libremente según fuera necesario. El concepto de controlador permitió que las pilas de protocolos de red estuvieran fuera del kernel, lo que facilitó enormemente el desarrollo y mejoró la confiabilidad general, aunque a un costo de rendimiento. También permitió que los sistemas de archivos externos fueran procesos a nivel de usuario, nuevamente para mejorar la confiabilidad. El sistema de archivos principal, aunque podría haber sido (y alguna vez fue) un proceso externo, se incorporó al kernel por razones de rendimiento. De no ser por esto, DNIX bien podría haberse considerado un micronúcleo , aunque no se desarrolló formalmente como tal. Los controladores pueden aparecer como cualquier tipo de archivo, estructura de directorios o dispositivo Unix 'nativo', y las solicitudes de E / S de archivos que el controlador en sí mismo no pudo procesar podrían pasarse a otros controladores, incluido el subyacente en el que se montó el controlador. . Las conexiones del controlador también podrían existir y pasarse independientemente del sistema de archivos, como una tubería . Un efecto de esto es que los 'dispositivos' similares a TTY podrían emularse sin requerir una instalación de pseudo terminal basada en kernel .
Un ejemplo de dónde un manejador salvó el día fue en el soporte de la estación de trabajo sin disco de ISC, donde un error en la implementación significaba que el uso de canalizaciones con nombre en la estación de trabajo podía provocar un bloqueo de recursos no deseado en el servidor de archivos. Se creó un controlador en la estación de trabajo para acceder a los campos de acceso a las tuberías con nombre afectadas hasta que se pudieran desarrollar las correcciones del kernel adecuadas. Este controlador requirió aproximadamente 5 kilobytes de código para implementar, una indicación de que un controlador no trivial no necesitaba ser grande.
ISC también recibió el derecho a fabricar DIAB DS90-10 's y DS90-20 máquinas como sus servidores de archivos. Sin embargo, el multiprocesador DS90-20 era demasiado caro para el mercado objetivo e ISC diseñó sus propios servidores y les transfirió DNIX. ISC diseñó sus propias estaciones de trabajo sin disco basadas en GUI para su uso con estos servidores de archivos y volvió a portar DNIX. (Aunque ISC usó estaciones de trabajo Daisy que ejecutaban Daisy DNIX para diseñar las máquinas que ejecutarían DNIX de DIAB, hubo una confusión insignificante internamente ya que el personal de diseño y diseño rara vez hablaba con el personal de software. Además, ¡el personal de diseño de hardware no usó ninguno de los sistemas! La broma era algo así como: "En ISC construimos computadoras, no las usamos "). El soporte de E / S asincrónico de DNIX permitió una programación sencilla impulsada por eventos en las estaciones de trabajo, que funcionó bien a pesar de que tenían relativamente recursos limitados. (La estación de trabajo sin disco GUI tenía un procesador 68010 de 7 MHz y se podía usar con solo 512 K de memoria, de los cuales el kernel consumía aproximadamente la mitad. La mayoría de las estaciones de trabajo tenían 1 MB de memoria, aunque luego hubo versiones de 2 MB y 4 MB, junto con 10 Procesadores MHz.) Una instalación completa podría constar de un servidor (16 MHz 68020 , 8 MB de RAM y un disco duro de 200 MB) y hasta 64 estaciones de trabajo. Aunque lento para arrancar, tal matriz funcionaría aceptablemente en una aplicación de cajero de banco . Además de la eficiencia innata de DNIX, el compilador DIAB C asociado fue clave para un alto rendimiento. Generó un código particularmente bueno para el 68010 , especialmente después de que ISC terminó con él. (ISC también lo redireccionó al coprocesador de gráficos TMS34010 de Texas Instruments utilizado en su última estación de trabajo). El compilador DIAB C, por supuesto, se usó para construir DNIX, que fue uno de los factores que contribuyeron a su eficiencia, y todavía está disponible (en alguna forma) a través de Wind River Systems .
Estos sistemas todavía están en uso al momento de escribir este artículo en 2006, en las antiguas sucursales de Seattle-First National Bank ahora con la marca Bank of America . Puede haber, y probablemente haya, otros clientes de ISC que todavía utilicen DNIX en alguna capacidad. A través de ISC hubo una presencia considerable de DNIX en Centro y Sudamérica .
Eventos asincrónicos
La llamada al sistema nativo de DNIX era la función de biblioteca dnix (2) , análoga a la función estándar Unix unix (2) o syscall (2) . Se necesitaron varios argumentos, el primero de los cuales fue un código de función. Semánticamente, esta única llamada proporcionó toda la funcionalidad apropiada de Unix, aunque era sintácticamente diferente de Unix y tenía, por supuesto, numerosas extensiones de sólo DNIX.
Los códigos de función DNIX se organizaron en dos clases: Tipo 1 y Tipo 2. Los comandos de Tipo 1 eran aquellos que estaban asociados con la actividad de E / S, o cualquier cosa que pudiera causar el bloqueo del proceso de emisión. Los ejemplos principales fueron F_OPEN , F_CLOSE , F_READ , F_WRITE , F_IOCR , F_IOCW , F_WAIT y F_NAP . Los de tipo 2 eran el resto, como F_GETPID , F_GETTIME , etc. El núcleo mismo podría satisfacerlos inmediatamente.
Para invocar la asincronicidad, se tuvo que crear un descriptor de archivo especial llamado cola de trampas a través del código de operación Tipo 2 F_OTQ . Una llamada de Tipo 1 tendría el bit F_NOWAIT OR-ed con su valor de función, y uno de los parámetros adicionales de dnix (2) era el descriptor del archivo de cola de capturas . El valor de retorno de una llamada asincrónica no era el valor normal sino un identificador asignado por el núcleo. En el momento en que se completa la solicitud asincrónica, una lectura (2) (o F_READ ) del descriptor del archivo de cola de trampa devolvería una pequeña estructura definida por el núcleo que contiene el identificador y el estado del resultado. La operación F_CANCEL estaba disponible para cancelar cualquier operación asincrónica que aún no se hubiera completado, uno de sus argumentos era el identificador asignado al kernel. (Un proceso solo podía cancelar solicitudes que actualmente eran de su propiedad. La semántica exacta de la cancelación dependía del manejador de cada solicitud, fundamentalmente solo significaba que cualquier espera debía terminarse. Se podía devolver una operación parcialmente completada). el identificador asignado por el núcleo, uno de los argumentos dados a cualquier operación asincrónica era un identificador asignado por el usuario de 32 bits. Con frecuencia, esto hacía referencia a un puntero de función a la subrutina adecuada que manejaría el método de finalización de E / S, pero esto era simplemente una convención. Fue la entidad que leyó los elementos de la cola de capturas la responsable de interpretar este valor.
struct itrq { / * Estructura de los datos leídos desde la cola de trampas. * / short it_stat ; / * Estado * / short it_rn ; / * Número de solicitud * / long it_oid ; / * Identificación del propietario proporcionada a pedido * / long it_rpar ; / * Parámetro devuelto * / };
Es de destacar que los eventos asincrónicos se recopilaron a través de operaciones normales de lectura del descriptor de archivo, y que dicha lectura podía hacerse asincrónica en sí misma. Esto tuvo implicaciones para los paquetes de manejo de eventos asíncronos semiautónomos que podrían existir dentro de un solo proceso. (DNIX 5.2 no tenía procesos o subprocesos livianos ). También es de destacar que cualquier operación de bloqueo potencial se podía emitir de forma asincrónica, por lo que DNIX estaba bien equipado para manejar muchos clientes con un solo proceso de servidor. Un proceso no estaba restringido a tener solo una cola de capturas, por lo que las solicitudes de E / S podrían priorizarse en gran medida de esta manera.
Compatibilidad
Además de la llamada nativa a dnix (2) , estaba disponible un conjunto completo de llamadas de interfaz libc 'estándar' . abrir (2) , cerrar (2) , leer (2) , escribir (2) , etc. Además de ser útiles para la compatibilidad con versiones anteriores, estos se implementaron de manera binaria-compatible con la computadora NCR Tower , de modo que los binarios se compilaron para ella funcionaría sin cambios bajo DNIX. El kernel DNIX tenía dos distribuidores de trampas internamente, uno para el método DNIX y otro para el método Unix. La elección del despachador dependía del programador, y el uso de ambos indistintamente era aceptable. Semánticamente eran idénticos dondequiera que la funcionalidad se superpusiera. (En estas máquinas, se usó la instrucción 68000 trap # 0 para las llamadas a unix (2) y la instrucción trap # 4 para dnix (2) . Los dos controladores de trap eran realmente bastante similares, aunque el unix (2 ) mantuvo el código de función en el registro D0 del procesador, mientras que dnix (2) lo mantuvo en la pila con el resto de los parámetros).
DNIX 5.2 no tenía pilas de protocolos de red internamente (a excepción de la pila de protocolos Ethernet delgada basada en X.25 agregada por ISC para su uso por su paquete de soporte de estación de trabajo sin disco), toda la red se realizó leyendo y escribiendo en Handlers. Por lo tanto, no había ningún mecanismo de socket , pero existía un libsocket (3) que usaba E / S asíncronas para hablar con el controlador TCP / IP. El programa de red típico derivado de Berkeley podría compilarse y ejecutarse sin cambios (módulo los problemas habituales de migración de Unix ), aunque podría no ser tan eficiente como un programa equivalente que usara E / S asíncrona nativa.
Manipuladores
Bajo DNIX, se podría usar un proceso para manejar solicitudes de E / S y extender el sistema de archivos. Este proceso se llamaba Handler y era una característica importante del sistema operativo. Un controlador se definió como un proceso que poseía al menos una cola de solicitudes , un descriptor de archivo especial que se adquirió de una de dos formas: con una llamada F_ORQ o F_MOUNT . El primero inventó una cola de solicitudes aislada, un extremo de la cual generalmente se pasaba a un proceso hijo. (Los programas de ejecución remota de red, de los cuales había muchos, usaban este método para proporcionar rutas de E / S estándar a sus hijos). Estos últimos se conectaban al sistema de archivos para que los controladores pudieran adoptar las solicitudes de E / S de archivos. (Los programas de inicio de sesión en la red, de los cuales había aún más, utilizaron este método para proporcionar rutas de E / S estándar a sus hijos, ya que la semántica de iniciar sesión en Unix requiere una forma para que múltiples procesos quizás no relacionados se conecten al estándar. Ruta de E / S al operador.) Una vez montado en un directorio del sistema de archivos, el controlador recibió todas las llamadas de E / S a ese punto.
Luego, un controlador leería pequeñas estructuras de datos de solicitud asignadas al núcleo de la cola de solicitudes. (Dicha lectura se puede realizar de forma sincrónica o asincrónica según lo desee el autor del controlador). El controlador haría lo que sea necesario para satisfacer cada solicitud, a menudo utilizando las llamadas DNIX F_UREAD y F_UWRITE para leer y escribir en el espacio de datos de la solicitud, y luego terminar la solicitud de forma adecuada utilizando F_TERMIN . Un manejador privilegiado podría adoptar los permisos de su cliente para solicitudes individuales a manejadores subordinados (como el sistema de archivos) a través de la llamada F_T1REQ , por lo que no necesitaba reproducir el esquema de permisos del subordinado. Si un controlador no pudo completar una solicitud por sí mismo, la función F_PASSRQ podría usarse para pasar solicitudes de E / S de un controlador a otro. Un manejador podría realizar parte del trabajo solicitado antes de pasar el resto a otro manejador. Era muy común que un manejador estuviera orientado a la máquina de estado, de modo que las solicitudes que recibía de un cliente se realizaban de forma asincrónica. Esto permitió que un solo gestor recibiera solicitudes de varios clientes simultáneamente sin que se bloquearan innecesariamente entre sí. Parte de la estructura de la solicitud era el ID del proceso y su prioridad para que un manejador pudiera elegir en qué trabajar primero en base a esta información, no había ningún requisito de que el trabajo se realizara en el orden en que se solicitó. Para ayudar en esto, fue posible sondear tanto las colas de solicitud como las de captura para ver si había más trabajo que considerar antes de abrocharse para hacerlo realmente.
struct ireq { / * Estructura de la solicitud entrante * / short ir_fc ; / * Código de función * / short ir_rn ; / * Número de solicitud * / long ir_opid ; / * ID de propietario que proporcionó al abrir o montar * / long ir_bc ; / * Recuento de bytes * / long ir_upar ; / * Parámetro de usuario * / long ir_rad ; / * Dirección aleatoria * / ushort ir_uid ; / * ID de usuario * / ushort ir_gid ; / * Grupo de usuarios * / time_t ir_time ; / * Solicitar tiempo * / ulong ir_nph ; ulong ir_npl ; / * ID de nodo y proceso * / };
No existía ninguna restricción particular sobre el número de colas de solicitudes que podía tener un proceso. Esto se usó para proporcionar facilidades de red para chroot de cárceles, por ejemplo.
Ejemplos de
Para dar una apreciación de la utilidad de los manipuladores, en ISC existían manipuladores para:
- sistemas de archivos extranjeros
- GRASA
- 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
- DEC LAT
- AppleTalk
- sistemas de archivos remotos
- DNET 's / net / machine / path / from / its / root ...
- NFS
- inicio de sesión remoto
- ncu ( DNET )
- telnet
- rlogin
- wcu ( GUI de DNET )
- ALMOHADILLA X.25
- DEC LAT
- ejecución remota
- rx ( DNET )
- remsh
- rexec
- extensión del sistema
- Windowman (GUI)
- vterm ( xterm- like )
- impresora de documentos (libreta de ahorros)
- dmap (tiempo de ruptura analógico)
- windowmac (puerta de enlace GUI a Macintosh)
- parches del sistema
- controlador de tubería con nombre
Extensiones de ISC
ISC compró las versiones 5.2 ( compatible con SVR2 ) y 5.3 ( compatible con SVR3 ) de DNIX. En el momento de la compra, DNIX 5.3 todavía se estaba desarrollando en DIAB, por lo que DNIX 5.2 fue lo que se implementó. Con el tiempo, los ingenieros de ISC incorporaron la mayoría de las características de su kernel 5.3 en 5.2, principalmente memoria compartida e IPC , por lo que hubo cierta divergencia de características entre las versiones de DNIX de DIAB e ISC. Es probable que la 5.3 de DIAB contenga más características SVR3 que las que terminó con la 5.2 de ISC. Además, DIAB pasó a DNIX 5.4, un sistema operativo compatible con SVR4 .
En ISC, los desarrolladores ampliaron considerablemente su versión de DNIX 5.2 (solo se enumeran las características que involucran al kernel en sí) en función de sus necesidades y las tendencias generales de la industria Unix:
- Soporte de estación de trabajo sin disco. El sistema de archivos del kernel de la estación de trabajo se eliminó y se reemplazó con un talón de comunicaciones Ethernet basado en X.25. El kernel del servidor de archivos también se amplió con un componente de acoplamiento que recibió las solicitudes remotas y las entregó a un grupo de procesos del kernel para su servicio, aunque se podría haber escrito un controlador estándar para hacer esto. (Más adelante en el ciclo de vida de su producto, ISC implementó servidores Unix basados en SVR4 estándar en lugar de los servidores DNIX. Estos usaron X.25 STREAMS y un programa de servidor de archivos personalizado. A pesar de la estructuración menos eficiente, la potencia bruta del Las plataformas utilizadas hicieron que el servidor fuera mucho más rápido. Es lamentable que este programa de servidor de archivos no admitiera todas las funciones del servidor DNIX nativo. Las cosas complicadas, como las canalizaciones con nombre , nunca funcionaron. Esta fue otra justificación para la canalización con nombre proceso de manipulador.)
- Soporte de gdb watchpoint usando las características de la MMU de ISC .
- La E / S asincrónica al sistema de archivos se hizo realidad. (Originalmente se bloqueaba de todos modos). Los procesos del núcleo (kprocs o subprocesos) se utilizaron para hacer esto.
- Soporte para un programa tipo truss o strace . Además de algunas reparaciones de errores en el mecanismo estándar de un solo paso ptrace de Unix , esto requirió agregar una función de adopción de proceso temporal para que el rastreador pudiera usar el mecanismo estándar de un solo paso en los procesos existentes.
- Extensiones del mecanismo de señal SVR4 . Principalmente para las nuevas señales STOP y CONT , pero también para las nuevas llamadas de control de señales. Debido a la falta de código fuente de ISC para los depuradores adb y sdb, la página u no se pudo modificar, por lo que las nuevas señales solo podrían bloquearse o recibir un manejo predeterminado, no pudieron ser detectadas.
- Soporte para rastreo de redes . Esto requirió extender el controlador Ethernet para que un solo evento pudiera satisfacer más de una solicitud de E / S e implementar condicionalmente el filtrado de hardware en el software para admitir el modo promiscuo .
- Duplicación de disco . Esto se hizo en el sistema de archivos y no en el controlador del dispositivo, por lo que los dispositivos ligeramente (o incluso completamente) diferentes aún se pueden duplicar juntos. Duplicar un pequeño disco duro en el disquete era una forma popular de probar la duplicación, ya que expulsar el disquete era una forma fácil de inducir errores de disco.
- 32-bit i-nodo , nombre de archivo de 30 caracteres, enlace simbólico , y pegajosos extensiones directorio al sistema de archivos. Se agregaron dispositivos / dev / zero, / dev / noise, / dev / stdXXX y / dev / fd / X.
- Listas de ID de grupo de proceso (de SVR4 ).
- #! ejecución directa del script.
- Multiplicación de puertos serie utilizando tarjetas de comunicaciones VMEbus basadas en Z-80 de ISC .
- Partición de intercambio móvil.
- Instantáneas de 'volcado' del núcleo de los procesos en ejecución. Soporte para comando de fusor .
- Función de renice del proceso. Programa de repriorización de tiempo compartido asociado para implementar prioridades flotantes.
- Una forma de "asaltar" un proceso, privándolo instantáneamente de todos los recursos de memoria. Muy útil para determinar cuál es el conjunto de trabajo actual , a diferencia de lo que todavía está disponible pero no necesariamente se está utilizando. Esto se asoció con una utilidad GUI que muestra el estado de las 1024 páginas del mapa de memoria de un proceso. (Este es el número de páginas de memoria admitidas por la MMU de ISC). En uso, "asaltaba" el proceso de destino periódicamente a lo largo de su vida y luego miraba para ver cuánta memoria se intercambiaba. Esto era útil ya que el entorno de producción de ISC solo se usaba Algunos procesos de larga duración, controlar la utilización y el crecimiento de la memoria fue clave para mantener el rendimiento.
Funciones que nunca se agregaron
Cuando el desarrollo de DNIX en ISC cesó efectivamente en 1997, se dejaron sobre la mesa una serie de características planificadas del sistema operativo:
- Objetos compartidos : existían dos bibliotecas cargadas dinámicamente, un cifrador para DNET y la biblioteca de imágenes de la GUI, pero la función nunca se generalizó. Las máquinas de ISC se caracterizaban por una falta 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 en sí ya tenía varios subprocesos que compartían un único contexto de 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 de esto.
- Listas de control de acceso : trivial de implementar utilizando un controlador ACL montado sobre el sistema de archivos de stock.
- Múltiples particiones de intercambio: DNIX ya usó espacio libre en el volumen seleccionado para el intercambio, habría sido fácil darle una lista de volúmenes para probar a su vez, potencialmente con límites de espacio asociados para evitar que consuma todo el espacio libre en un volumen antes. pasando a la siguiente.
- Depuración remota del kernel a través de gdb : todas las piezas estaban allí para hacerlo a través del puerto serie habitual o a través de Ethernet utilizando el software de enlace X.25 integrado del kernel, pero nunca se ensamblaron.
- Soporte 68030 : los prototipos de ISC nunca se completaron. Se construyeron dos tarjetas enchufables del procesador piggyback, pero nunca se usaron como más que las 68020 más rápidas. No eran fiables, ni eran tan rápidos como podrían haber debido a tener que encajar en un enchufe 68020. La MMU de ISC de cambio de contexto rápido se dejaría deshabilitada (y se dejaría de lado por completo en las unidades de producción propuestas), y en su lugar se usaría la incorporada del 68030, utilizando un derivado del código 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 direccionabilidad era muy limitada. La MMU 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. Aunque esta MMU sería más lenta, la velocidad general más rápida del 68030 debería compensarlo 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.
Ver también
- Cronología de los sistemas operativos
- Cromemco Cromix
Referencias
- ^ Dnix
- ^ Historien om DIAB - Dataindustrier AB
- ^ Accept () escalabilidad en Linux