ESTUDIOS CON RECONOCIMIENTO DE VALIDEZ OFICIAL NUMERO 00922681 DE FECHA 23 DE JUNIO DE 1992 DISENO Y SIMULACION DE SISTEMAS OPERATIVOS TESIS QUE PARA OBTENER EL GRADO DE MAESTRIA EN CIENCIAS DE LA COMPUTACION PRESENTA: EUGENIO JACOBO HERNANDEZ VALDELAMAR, ASESOR: ENRIQUE CALDERON ALZATI MEXICO, DF. AGOSTO, 2003Disefio y simulacion de sistemas operatives ~ Eugenio Jacobo Hemsindez Valdelarmar DISENO Y SIMULACION DE SISTEMAS OPERATIVOS EUGENIO JACOBO HERNANDEZ VALDELAMAR, ys ‘commons Ce aoe eid Eres libre de: @® sees enraury some siscenens Bajo las condiciones siguientes: Aitucion. sees esoncca lentes see coe noe leernos espacnesoss ner a pmol aust Sears 8 in comers pusentineaie avn ssn fon No Darvas. No asta etic gue states, Sosatoae © gneren une obra servese 9 sane oe ies = Mean 2 saibus a obra tone ue dlr Ben ola ea rmboa de is ear ta ob. + Mune de cota candela pune 9 aplcanetlae oboe ol porian del tulr does cerectoa deste 1 eomen ane scent meroneata 0 esonge ios anacren moras caste CP vary ey wy eee ee ope ee erred ere hitp:/ereativecommons.orylicenses/by-ne-nd/2.S/x/legaleode ‘Cualquier comentario 0 sugerencia es bien recibido en jack _hv@yahoo.comDisefio y simulacion de sistemas operatives ~ Eugenio Jacobo Hemsindez Valdelarmar Contemplando una idea. Vladimir Islas ValdelararDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Agradecimientos ‘Ami familia, en especial a mi madre Guadalupe Valdelamar, a mi padre Jacobo Hernandez y a mi tia Maria Luisa por su apoyo. ‘A mi esposa y compafiera Mar Sallago por su alegria y aliento (gracias por mostrarme otras perspectivasn); y a toda la familia y amigos en Argentina, en especial a Pedro, Lis y Leo por su amistad. ‘A mis profesores: Enrique Calderén, Carlos Calderén, Miguel Orozco, Alejandro Dominguez, Miguel Leal; Marcos Calderén y Edgar Herrador (después de todo, se superaron las dudas de ese imitico curso). ‘A mis colegas: Jorge Vasconcelos por su ejemplo de perseverancia en la vida académica y sus comentarios a este trabajo; Miguel Armas por compartir muchos alucines académicos y @ Roberto Murcio por sus comentarios a este trabajo en sus inicios. A los buenos amigos del Instituto de Quimica de la UNAM, en especial a Jaime Lagunez por abrirme la perspectiva de las consideraciones bioldgicas en cuestiones de sistemas cémputo. ‘Allos alumnos de licenciatura de la FAR del curso de sistemas operativos en el periodo 2002-3 (Gonzalo, Humberto, Gerardo, Josué, Héctor, Enrique, Luis) y 2003-1 (Lizethe, Rodrigo, Oscar, Christian, J. Ignacio, Josué), por la oportunidad de poner en préctica los resultados de este trabajo y el reto de transmitirles los conocimientos de un tema complejo y apasionante. A Paco Otero, Hugo Gutiérrez y a Rodrigo Herrera por su amistad. A Antonio Martinez por demostrarnos que es posible vivir la vida fuera del sistema. Ala familia Morn; Alfonso Sr. y Jr., Manolo: gracias por su apoyo y amistad. ‘Al profesor Rubén Lara por su gran labor en la ensefianza del kendo. To Rachael Dunne, Oisin & friends, (thanks for the opportunity of visiting Ireland, even when T preferred to stay in México; it was a great time) and Alan Armijo (thanks for’ offer me the opportunity of going to the US even when the odds were against the idea).Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Resumen Estamos en una época donde parece que el interés por cémo funcionan las cosas 0 cémo hacerlas, pasa a un segundo plano a raiz de estar més ocupados utlizéndolas. El software no es la excepcién, Toda aplicacién que se use tiene un proceso de desarrollo, y mas atin, cuenta con Un sistema que soporta su ejecucién. Estas piezas de ingenieria de software que nos hacen la vida mas amable son los sistemas operativos, y vale mencionar que sin ellos, seguramente seguiriamos requiriendo de operadores de computadora super especializados. Este trabajo es una investigacién acerca de los sistemas operativos. El objetivo es prover una visién integral de este tipo de sistemas; desde sus antecedentes y fundamentos, hasta un analisis de sus componentes y el establecimiento de criterios de disert. He tratado de mantener un balance entre la teoria y la practica, incluyendo algunos proyectos de desarrollo que han arrojado como producto no solo el cédigo de los simuladores propuestos, sino la experiencia de las consideraciones involucradas en hacer un sistema operativo; experiencia que he tenido oportunidad de compartir con mis estudiantes. Ademds de los temas clésicos como administracién de memoria, procesos y dispositivos, se incluye una seccién dedicada al disefio de sistemas operativos, asi como una completa referencia de las arquitecturas existentes en este tipo de sistemas, y las tendencias a futuro. Este trabajo seré de utilidad para todos aquellos usuarios, administradores y desarrolladores de sistemas operativos, asi como para cualquier profesional de las ciencias de la computacién.Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez ValdelamnarDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Contenido Introduccién ——___________! Capitulo 1. Fundamentos de los Sistemas Operativos 7 1.1 ,Qué es un sistema operative? 7 1°" Definiciones 8 12 Caracteistcas principales 10 1.2 _Principales conceptos de los Sistemas Operativos 12.1 Administracién de procesos. 1.2.2 Administracién de memoria 12.3 Lagestiénde la integridad 124 Administracién de dispositivos 1.2.5 Almacenamiento secandario 1.2.6 Transmisién de datos einformacién 1.2.7 Niileo del sistema (Kernel) 1.28 Comanicacién con el usuario 13 Desarrollo histor Tal Enelptincipio,, 1.3.2 Procesamiento por lotes y monitores 133 134 de los Sistemas Operativos Sistemas de operacién simultanea de periféricos en linea 3.4 _ Sistemas de Multiprogramacién + Sistemas de tiempo compartido (Timesharing) + Sistemas de Tiempo Real 1.3.5 Sistemas Multiprocesador, distribuidos yen red 13.6 — Computadoras Personales 1.4 Comentarios 1.5 Obras consultadas 33 Capitulo 2. Funcionamiento basico de un sistema operative 35 2.1 El hardware y la ejecuciin de programas 2.1.1 La.unidad central de procesamiento, 2.12 Lamemoria 213 Ejecucidn de programas 2.1.4 Interaccién entre los componentes de hardware + Tipos de interrupciones 2.2 Software para el control del hardware 22.1 El papel del BIOS + Rutinas del BIOS + Secuencia de arrangue + ELBIOS yel sistema operative 222 — Cargador del sistema + Carga desde un CD-ROM + Carga por medio de conexién en red 223” Inicio de la ejecucién del sistema operative 224 _ Proteccién del hardware + Funcionamiento det keme! 2.3 Comentarios ssDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar 24 Obras consultadas Capitulo 3, Simulacién de Hardware y Sistemas Operativos. 3.1 La simulacién en el disefto de sistemas operativos 3.2 Emulacién y Simulacién de hardware 3.2.1 Emulacién de hardware + 4Cémo se instrumenta un emulador? 3.2.2” Sinulacién de hardware 3.3 Maquinas virtuales 331 Elsistema P 3.4 Plataformas de simulacién de Sistemas Operativos 34.1 Java Operating System Simulation 342 _ NachOS + Lamiquina Nachos 343 RCOS 3.5 Simulacién de un Sistema Operative minimo 3S. hardware: URM_ 35.2 _ El/software: SOM. 3.5.3 Consideraciones para el modelado de dispositives de E/S 354 — Resultados 35.5 morfo-Hardware 3.6 Comentarios 3.7 Obras consultadas Capitulo 4, Administracién de la memoria 4.1 La memoria 4.11 Asignacién de dircociones 4.1.2 La unidad de administracién de memoria (MMU). + Memoria asociativa 4.1.3 Manejo estitico y dindmico de la memoria 4.14 Carga de programas en memoria + Overlays + Relocalizacin 4.2 Administracién de la memoria 42.1 Administracién manual 42.2 Administracién automiética 423 Esquemas de Administracién + Monoprogramacién sin intercambio ‘Multiprogramacin con particiones fjas Particiones de Longitud Variable Registro del Uso de la Memoria Intercambio de procesos entre mei Intereambio (Swapping) ‘Memoria virtual 4.24 Problemas de la administracion de memoria 42.5 Caso de estudio: Sistema de administracién de memoria de Linux ia y disco 43. Asignacién de la memoria 43.1 Alojamiento contiguo y no contiguo 43.2 Estrategias de asignacién 433 Fragmentacién y compactacin vi 7 59 60 63 6 6s 65 66 67 68 68 1 n B 5 6 78 81 83 84 86 87 39 89 90 91 92 93 93 94 95 96 97 98 98 99 100 101 102 103 104 105 107 108 110 no nL MLDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar + Subalojadores, 12 434 Paginacién n2 + Reemplazo de pagina ns 43.5 Segmentacién 116 43.6 Segmentacién con paginacién 7 44 Simulacién del servicio de administracién de memori 9 45 Comentarios 122 45 Obras consultadas 123 Capitulo 5, Administracion de procesos 125. 5.1 Bjecucién de programas y procesos 125 S.L1 Modelos de ejecucién 125 5.12 Procesos 127 S13 Liles, 128 5.14 Representacidn de los provesos 129 5.15 Creacién de procesos 130 5.1.6 Estados de un proceso 132 5.17 Colas de procesos 133 + Llamadas de servicios 134 5.18 Operaciones de manipulacion de procesos 134 5.19 Por qué usar provesos? 135 5.2 Planificacién de procesos 136 5.2.1 Tipos de planificacién 137 + Planificacién del CPU 138 + Planificacién de largo plazo 139 + Planificacién de mediano plazo 140 + Caso de estudio: Sistema de planificacién de procesos de Linux HL 5.2.2 Algoritmos de planificacién 142 + Algoritmo de planificaciin FCFS (First Come - First Served) 143 + Algoritmo Round-robin 145 ‘+ Planificacién por prioridad 146 ‘© Algoritmo del trabajo mis corto primero (Shortest Job First) 147 ‘+ Maltiples colas de prioridad (MPQ) 148 + Planificacién de dos niveles, 150 + Planificacién por herencia (Inheritance scheduling) 151 + Planificacién evolutiva, 1st 5.3 Simulacién del servicio de administracién de procesos 152 5.4 Procesos concurrentes Ass 54.1 Sineronizacién de procesos 159 + Semiforos 161 + Candados (Locks) 162 + Monitores y variables de condicién 163 + Interblogueos 167 + Preveneidn y tratamiento 168 S42 _ Comunicacién entre procesos 170 + Elesquema productor-consumidor 170 + Mensajes 171 + Tuberias (pipes) I + Caso de estudio: Comunicacién entre procesos en Linux 174 54.3 Comunicacién entre procesos en Sistemas Distribuidos 175 54.4 Modelo cliente-servidor 17 + Direcelonamiento, 177 viiDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar 54.5 Llamadas a Procedimientos Remotos (RPC) 178 SS Comentarios 180 5.6 Obras consultadas 181 Capitulo 6. Administracién de dispositivos, almacenamiento y comunicaciones. 183 6.1 Administracién de dispositivos y periféricos 184 6.1.1 Dispositives de Entrada ~ Salida 185 61.2 Controladores de Dispositives 18s G3 Mangjadores de dispositivos (device drivers) 187 6.14 Acceso Directo a Memoria 190 61.5 Casode estudio: Manejo de dspositives en UNIX 191 62 Administracién de archivos 193 62.1 Medios de almacenamiento 194 62.2 Manejador de discos 195 623 Archivos 196, 62.4 Elsistema de archivos 197 + Representavién de archivos y estructura del Ssterna de archivos 199 + Operaciones soportadas por el sistema de archives 202 + Asignacisn del espacio de almacenamiento 208 + Métodos de acceso en ls sistemas de archivos 205, + Algoritmos de planificacién de lectura y escritura 205, + Tolerancia a fallas 206 + Elconcepto de sistema virtual de archives 206 62.5 Nuevos enfoques en el manejo de archivos 207 62.6 Casode estudio: Sistema de archivos y conitol de disposiivos en Linux 208 63 Comunicaciones en red 210 63.1 Redes de computadoras 2 + Estructura y configuraciones de redes 212 + Inferconexién de computadaras 218 63.2 Organizacin dl software dered 21s, + Protocolos 216 + Caso de estudio: TCP/IP 218 + Sockets 219 ‘Caso de estudio: Windows 9X en ed 21 Interfaces de dispositives dered 221 + Arquitectura para protocolos 22 + Arquitectura para clientes de zedes 22 + Mecanismos de comunicacién entre procesos (IPC) 223 + Instalacién y configuracién de las tarjetas de red 23 64 Comentarios 223 65 Obras consultadas 225 Capitulo 7. Disefo de sistemas operativos 227 7A Elsoftware y sus earacteristicas 228 TAL gPor qué es necesario un sistema operative? 229 712 {Para qué escribir un sistema operative? 230 7.2 Desarrollo de sistemas de software 230 721 Proceso de desarolio de sofware 230 72.2 _Ingenietia de software 231 + Concepto de ciclo de vide 232 + Fases genérieas dela ingenierfa de software 23 viiiDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar + El proceso de disefio. + Etapas del diseito de sistemas 7.3 Arquitectura de software 7.3.1 Importancia de la arquitectura de sofware 732 Eldisefo de la arguitectura 733 Elementos de una arquitectura de software © Vistas (estructuras) + El modelo de arquitectura 471 vistas + Vista de a arquitectura por eapas, + Estilos arquitecténicos 734 Patrones arquitecténicos + Elpatrén Layers + El patrén Microkemel + Elpatrén Broker 738 Desamollo basado en la arquitectura 714 Disefio sistemas operativos: enfoque orientado a la arquitectura 74.1 Preguntas importantes: en busca de requerimientos 74.2 Meas del disco 743 Estructura del sistema operative 744 Mecanismos y politicas 7S Disefio de sistemas operativos: el enfoque de los desarrolladores 78.1 enfoque de diseiio mis simple 75.2 Consideraciones de disefio de sistemas operatives 783 _ Disoio de kernels + Clasificacién de los kernels + Griterios de planificacién 784 Consideraciones sobre ia codific TSS Uso de estindares y portabilidad én del sistema 7.6 Diseiio de sistemas operativos: Ia interaccién con el usuario 7.6.1 Interaceién humano-computadora 7.6.2 Interfaz basada en texto, 7.63 Interfaz grafica de usuario 7.644 Interfaces alternativas 7.6.5 Disedo de interfaces de usuatio 7:1 Disefio de sistemas operativos: la administracién de sistemas 78 Comentarios 7.9 Obras consultadas Capitulo 8. Arquitecturas de Sistemas Operatives 8.1. Representacién de la arquitectura 8.2 Arquitecturas de Sistemas Operativos 8.3 Arquitectura de kernel monolitico 84° Arquitectura de capas y anillos. 85. Arquitectura de maquina virtual 8.6 Arquitectura de microkernel y multihilado 8.7 Arquitecturas Orientadas a Objetos, 87.1 Sistemas operatives basados en componentes 235 235 237 238 239 24 242 287 288 290 293 295 298 301Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar 88° Arquitectura cliente-servidor 302 + Implantacién del modelo CIS para sistemas operatives distribaidos 304 89 Arquitecturas en red y distribuidas 30s 89.1 Criterios de disefo de sistemas distribuidos 308 89.2 Mach 309 8.10 Arquitecturas adaptables 312 8.11 Arquitectura de Exokernel 314 8.12 Arquitecturas orientadas a agentes 317 8.13 Comentarios 319 8.14 Obras consultadas 321 Resultados, conclusiones y perspectivas 325 a. Resultados 325 b. —Aportaciones 326 €. Conelusiones, 328 c.1 jPor qué seguir desarrollando nuevos sistemas operatives? 329 2 Los sistemas operatives y el desarrollo de marcos conceptuales (frameworks) 330 3 Tendencias en e! desarrollo de sistemas operatives 330 d.— Perspectivas, 330 ¢. Referencias 332 Bibliografia 333 Glosario. 335 Apéndices 341 ‘Apéndice A. Programacién de Cargadores (sectores de arranque) 341 Apéndice B. Simulaci6n de un sistema minimo de hardware y su sistema operative __346 Apéndice C. Simulador del servicio de administracién de la memoria 387 Apéndice D. Simulador del servicio de administracton de procesos 372 Apendice E. Caso de estudio: Implementacién de un microkernel 384Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Lista de figuras y tablas, Organizacién del wabajo 3 Figura 1.1 Vista de los programas de sistema y de aplicacién 8 ura 1.2 El $O administra los recursos de hardware y software de la computadora, y provee un medio estable y consistente donde las aplicaciones puedan usar el hardware, 8 ura 1.3 Soporte de software necesario para aprovechar los recursos del hardware. iL Tabla 1. Recursos de la arquitectura, administracién del sistema operative y abstracciones del usuario... 12 Figura 4 Esquema de los diferentes tipos de memoria en um sistema de eémputo, B Figura 1.5 Niveles de interacci6n de um Shell... sanneninmnenenecee IT ura 1.6 Ejemplos de interfaz gréfica de usuario: (a) el sistema NeXT: (b) Mac OS X. 18 Figura 1.7 Cronologia del desarrollo de las computadoras_y los sistemas operativos. 19 tra 1.8 Esquema de operacién de las primeras computadoras, 20 ier 1.9 eqn bin den memoria de a computsors. con proces po es Genin residente., 2 ura 1.10 Esquemas hésicos de procesamiento, Nétese como el tiempo desperdiciado ha ido disminayendo, 2B ura 1.11 Esquema de sistema de multiprogramacién (o multtarea), donde varias tareas son cjecutadas simulténeamente 24 Figura 1.12 Esquema de ejecucién de dos procesos con y sin muliprogramacién.. 25 ‘gua 1.13 Esquema de um sisteraa de tiempo compartido.. 26 ‘igura 1.14 Esquema de un sistema de control, en donde deben ser aceptados y procesados gran cantidad de sucesos 27 ura 1.15 Configuraciones de multiprocesamicnto asimétrico(a) y simétrico(b). 28 Figura 1.16 Esquema de un sistema operativo distribu... nn 30 Figura 17 Las primeras PCs: (a) MITS Altair (1974), (b) Radio Shack TRS-80 (1977), (¢) Apple [ (1976), (4) Apple Lisa (1983). 31 Figura 2.1 Modelo de Von Neumann. 36 ura 2.2 El procesador y demés dispositivos se conectan por medio de enlaces fsicos conocides como bases. 36 ‘gura 2.3 Modelo de un microprocesador simple... ern sonnei 3D Figura 2.4 El CPU accede diferentes tipos de memoria, 39 Tabla 2, Comparacién de un programa en lenguaje de alto nivel, ensamblador y eédigo maquina. 40 ura 2.5 Esquema de la ejecucién de un programa 41 ‘igura 2.6 Los componentes de hardware pueden comunicarse con el CPU mediante controladores... 42 Figura 2.7 Software relacionado al control del hardware. 46 ura 2.8 Secuencia del inicio de ejecucién del sistema operative, 32 Figura 3.1a Esquema de la arquitectura del FLUX OSKit. 61 Figura 3.1b Esquema de la arquiteetara del Palm OS. a ura, 3.2 Emulacién interpretativa. 64 ‘gura 3.3 Emulacién de compilacién dindmica, 64 Figura 3.4 Clases y métodos del JOSS. 69 ura 3.5 Forma en que los diferentes componentes de Nachos estén ligados durante la ejecuci6n........72 Figura 3.6 Arquitectura del RCOS. 5 Figura 3.7 Modelo del simulador con un cargador de programas. 8 Figura 3.8 Modelo del simulador eon un SOM para una URM modificada, basado en el concepto de un ‘monitor resident 80 ‘igura 3.9 Patrén de disehio Modelo-Vista-Controlador. 84 Figura 3.10 Esquema del modelo. morfo-Hardware 85 Figura 3.11 Modelo de clases de morfo-Hardware v.0.1 85 ra 3.12 Modelo de clases de morfo-Hardware v.0.2. 86 Figura 4.1 Vista simplificada del espacio de direcciones en la memoria. 90 Figura 4.2 La MMU se sitia justo entre el CPU y la memoria 972 tara 4.3 Cuando el CPU quiere acceder a la memoria, le manda la direccién que quiere a la MMU quien xiDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar la fraduce en ofra direceidn que le pasa a la unidad de memoria. senses ura 4.4 Carga de un programa en memoria virtual 94 Figura 4.5. Esquema de un sistema que implementa recubrimientos, 95 igura 4.6 Esquemas de organizacién de memoria con manejo de dos particiones. 99 ‘igura 4.7 Administracién con particiones fijas 100 ‘igura 4.8 Administracién con particiones variables. sen sonnei LOL ura 4.9 Administracién con mapa de bits 102 Figura 4.10 Administracién con lista ligadas. 102 ura 4,11 Intercambio. 105 ura 4.12 Administracién con memoria virtual 106 Figura 4.13 Dependencias y flujos de control y datos en el administrador de memoria. 109 Figura 4.14 Estructara del administrador de memoria de Linux. 110 ura 4.15 En la paginacién el tamafo de la pagina debe ser una potencia de 2. 13 ura 4.16 Traduccién de direcciones en un sistema de paginacién 1B ura 4.17 Diteccionamiento en MS-DOS usando segmentacidn (8086-16 bits). Capacidad de direccionamiento 2°”-1'048,576- IMB. na igura 4.18 Traduccién de direcciones en la segmentacién, 116 ura 4.19 Traduccién de ditecciones en un sistema con segmentacién 17 Figura 4.20 Método de segmentacién y paginacién, 18 ra 4.21 Traduccién de direceiones en un sistema con segmentacién y paginacién. 18 Figura 4.22 Los esquemas de patticiones fijas, variables y paginacién manejan programas como bloques iicos, 119 igura 4.23 La segmentacién y Ia segmentacién con paginacién son més aptos para manejar programas y ‘médulos dindmicos 120 Figura 4.24 Modelo de clases del simalador de administracién de memoria. 121 ra 4.25 Ejecueién del simulador. 122 Figura 5.1 Modelos de ejecueiénen sistemas de eémpato 126 a 5.La Esquema de un sistema monotarea 126 ra §.1b Esquema de un sistema multitarea, 127 Figura 5.2 Esquema del intereambio de procesos con el CPU en un sistema multitarea, 129 ura 5.3 Esquemas de estados y transiciones de un proceso 132 Figura 5.4 Niveles de planificacién 137 fa 5.5 Esquema de las dependencias y fujos de control y datos en el planificador de procesos.... 141 ura 5.6 Estructura del planificador de procesos de Linux. 142 ‘gura 5.7 Para un quantum”1 se presenta la secuencia de ejecucién de procesos 146 Figura 5.8 Ejemplo de los algoritmos SIF y SRTF. 148 Figura 5.9 Colas miltiples de prioridad. 149 5.10 Planificacién de 2 niveles. 151 ura 5.11 Esquema del famcionamiento de la adrainistracién de procesos. 152 ‘gura 5.1la Modelo de clases del simulador de administracién de procesos. 154 Figura 5.12 Fjecucién del simulador. 155 tara 5.12 Los procesos PI y P2, asi como P2 y P3 son concurrentes, en cambio P3 y PI no lo son... 155 Figura 5.13 Interbloqueo, 167 ura 5.14 Esquema donde los procesos que requieren acceder a un recurso compartido, 170 ‘gura 5.15 Entrega de mensajes con miltiples colas. 173 Figura 5.16 Estructara del subsistema IPC de Limx 175 Figura 5.17 Esquema de procesos que se ¢jecutan en una computadora y en un sistema distribuido...... 176 Figura 5.18 Modelo cliente-servidor en un escenario distribuido. 177 ura 5.19 Esquema de invocacién local y remota de procedimientos 179 Figura 6.1 Capas del sistema de entrada-saida. 184 Figura 6.2 Arquitecturas de entrada-salida y disposiciones de los dispositives conectados al bus. 186 Figura 6.3 Esquemas de E/S y su acceso mediante instrucciones en ensamlador o.snennneninnnnne 186 ‘igura 6.4 Capas del software de entrada-salida. 188 Figura 6.5 Flujo de operaciones en un manejador de dispositive, 189 ara 6.6 Flujos de E/S por cl DMA. 190 ‘gura 6.7 Estructura de un manejador de discos. 195 xiiDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar ura 6.8 Objetos del sistema opcrativo y sus operaciones relacionadas con archivos. ....usureueuesees 197 ura 6.9 Esquema del sistema de almacenamiento secundari. 197 Figura 6.10 Esquema del sistema de almacenamiento terciario, 199 ‘igura 6.11 Formato de un archivo cjecutable 200 ‘igura 6.12 Organizacin de archivos con directorios. 200 jgura 6.13 Representaciones de archivos en UNIX, MS-DOS y Windows NT sone 201 ura 6.14 Kjemplos de estructuras en sistemas operativos como UNIX, MS-DOS y Windows. 202 Figura 6.15 Esquema de Ia aplicacién de operaciones de acceso y manipulacién en un archive 204 ura 6.16 Sistema virtual de archivos de Linux. 209 ura 6.17 Estructura de] administrador de archivos de Linux 210 Figura 6.184 Algunas ejemplos de las topologias que una red puede adoptar 213 Figura 6.18b Modelo OSI y los equivalentes en el modelo de protocolos TCP/IP 214 ura 6.19 Arguitectura de Netware 2.2. 214 ara 6.20 Estructura del subsistema de red de Linux 216 ura 6.21 Conjunto de protocolas TCP/IP y su relacién con el modelo OSI. 218 Tabla 3. Relacién de dispositivos de eémputo y sus sistemas operatives. 29 igura 7.1 Esquema del proceso unificado de desarrollo (RUP) 231 ra 7.2 Cielo de vida en cascada, 232 Figura 7.3 Visiones de un sistema de software 27 ura 7.4 La definicién de la arquitectura estd entre el andlisis de! sistema y su disco. 240 Figura 7.5 Descomposicién de elementos de disefo. 2a Tabla 4, Estructuras de una arquitectura de softwa 243 igura 7.6 Vistas posibles de un elemento de disefio (Iogica, concurrente o de instalacién), 244 ‘gura 7.7 Algunos tipos de estilos arquitecténicos. 247 Figura 7.8 Dingrama de clase del pattén microkernel 250 ra 7.9 Vista de capas de la arquitectura de un sistema operative 256 Figura 7.10 Dispositivos de interfaz 268 7.11 Interfaz de usuario del MS-DOS 269 ura 7.12 Patrén de diseto Interpreter. 270 Figura 7.13 Interfaz de la aplicacién shell de MS-DOS 270 ura 7.14 Interfaz grifica GNOME en Linux{7.87] 2m Figura 7.15 Patron MVC como hase de una GUT 22 17.16 Elementos de la interfaz de usuario de Swing en Java 272 ra 7.17 Arguitectura de la GUI del WCEEA. 273 ‘gura 7.18 Arquitectura del Mac OS X y su interfaz de usuario Aqua 275 Figura 7.19 Consideraciones para el desarrollo de software. 278 Figura 7.20 DiseBo de sistemas operatives. 279 fa 8.1 Arquitectura de Windows NT representada en un esquema de médales. 286 ura 8.2 Especificacién formal de alto nivel de la arquitectura de Windows NT usando UML (paquetes y relaciones) 287 Figura 8.3 Arquitectura de kemel monolitico 289 ura 8.4 Arquitectura conceptual de Linux 290 Figura 8.5 Esquema de la organizacién en eapas de un sistema operativo 201 ura 8.6 Organizacién del sistema operativo en anillos. 201 ‘gura 8.7 La caracteristica central de la arquitectura de Mac OS X es la divisién en capas del software del sistema 292 Figura 8.8 Esquema de una arquitectura de méquina virtual, 293 Figura 8.9 Niveles de miquinas virtuales 204 ura 8.10 Conviveneia entre el sistema operative native y 295 el ereado por la méquina virtual 295 Figura 8.11 Esquema de la arquitectura de un microkernel. Pueden identificarse los modas de operacién (odo kernel y modo usuario), asi como los procesos del sistema y los provesos de USUIHO non 296 ‘igura 8.12 Esquema de la arquitectura del Palm OS. El nicleo de este sistema es el microkemel AMX (Kadak) que implementa multiprocesamiento 297 ura 8.13 La arquitectura de paso de mensajes del QNX RTOS forma un bus de software que permite conectar o desconectar los médulos de! 10 que se necesiten, sin reiniciar el sistema, 298 xiiiDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Figura 8.14 En el corazén del JavaOS se encuentra la maquina virtual de Java (JVM). Los servicios del sistema, manejadores, applets y aplicaciones se ejecutan en la VM y un microkernel provee los servicios basicos de la plataforma, 300 ‘igura 8.15 La red de médulos de sofware que forma una aplicacién puede visualizarse cn distintos niveles 301 ‘gura 8.16 Arquitectura del sistema operativo G0 sossonnnnnnnennnn : sna 302, ‘igura 8.17 Arguitectura del sistema X Window, para el intercambio de mensajes de interfaz grafica de usuario, 304 ura 8.18 Esquema de operacién de un sistema operativo de red 305 ura 8.18a Arquitectura de Windows NT en referencia al modelo OSI 306 Figura 8.19 Esquema de operacién de un sistema operativo distribuido 307 Figura 8.20 Esquema del middleware y entornos distribuidos 308 ura 8.21 Esquema de la arquitectura de Mach. 310 Figura 8.22 Arquitectura del microkemel Darwin del Mac OS X que integra el kernel Mach 3.0 y servicios. del BSD UNIX. 312 Figura 8.23 Fstructura de un sistema exokernel. Las aplicaciones usan sus propias librerias de Sistema Operativo (Library Operating System (LibOS)) que a su vez usan c] exokemel para cargar y descargar recursos de hardware. Figura 8.24 Esquema de un servidor Web montado en un SO convencional ‘gura 8.25 El solicitar una pagina HTML desencadena una scrie de procesos que cl SO tiene que hacer para darle el soporte a la aplicacién, lo cual no necesariamente puede ser Optimo. Fn el segundo diagrama pueden apreciarse las dependencias del sistema de administracién de memoria de Linux. 315 igura 8.26 El exokernel provee la proteccién del hardware y las librerias de aplicacién, pero el control lo tiene la aplicacién, lo que elimina procesos que el servidor Web no necesita 316 Figura 8.27 Un sistema de exokernel simplificado con dos aplicaciones, cada una ligada con Su propia libOS y compartiendo piginas por medio de un registro 316 Figura 8.28 Arquitecturas de sistemas operatives y sus earacteristicas 320 29.1 Simulador de administracién de memoria con particiones fijas (Oscar Cecefa). 328 ura 9.2 Simulador de administracién de procesos (Chistian Islas) 328 Figura 9.3 Simulador de administracién de procesos (Josué Huizar) 328 xivDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Introduccion Algunos ven las cosas como son y preguntan:éPor qué? Yo suefio en lo que nunca existié y pregunto:éPor qué no? Robert F. Kennedy Las computadoras desde un principio han sido maquinas complejas (y un gran logro técnico iniciado por Babbage en el siglo XIX y desarrollado en el siglo XX), compuestas de diversas partes fisicas (el hardware), las cuales realizan acciones cuando se les dan instrucciones (el llamado software). Los conjuntos ordenados de instrucciones son lamados programas, y son los que le dicen a la computadora como debe hacer diferentes cosas con objetivos especificos y particulares. Es un tipo especial de programas lamados sistemas operativos, los que permiten a la computadora brindar una plataforma para realizar una gran variedad de tareas complejas. La idea de realizar notas y hasta un libro de sistemas operatives nacié en 1997 cuando daba un curso relacionado al tema en la Fundacién Arturo Rosenblueth (el titulo de ese proyecto era "Sistemas operativos: Teoria y préctica"), sin embargo por motivos de trabajo la idea quedé en el bau, Fue hasta 1999 (tal vez un poco antes) con el advenimiento de un movimiento importante en el pafs respaldando a Linux (por parte de entusiastas estudiantes de diversas universidades) ue decidi retomar el tema de los sistemas operativos, Una motivacién adicional aparecié durante el tiempo que pasé colaborando en el Instituto de Quimica de la UNAM; hubo una pregunta que me intrigé cuando charlabamos sobre las analogias de los mecanismos celulares con las computadoras: "Si el niicleo celular era el hardware, écual era el software (y el sistema operativo) de la célula?" Aunque se comenté que el ADN podia onsiderarse como el software de control, me parecié que debia estudiar a fondo la teoria de los sistemas operatives para un andlisis futuro del tema, Después de investigar cai en cuenta de algunos hechos importantes: + Eldesarrollo de este tipo de sistemas esté en manos de una élite de desarrolladores (ya sean los apoyados por universidades 0 comparias, 0 los que lo hacen como pasatiempo; esfuerzos sin duda, loables). Aunque hacer sistemas operativos no es una de las ofertas de trabajo que salgan a menudo en los periédicos, el conocimiento de este tema es obligado para cualquier profesional del area de cémputo. + La bibliografia relacionada es escasa e importada (aunque hay traducciones) y en general més teérica que préctica. Esto tiltimo no ha tenido un balance (hay obras con mucha teoria y ‘otras con la mitad de la publicacién con listados de cédigo fuente) y ante todo, no ha reportado la experiencia de las personas 0 equipos de trabajo, exponiendo cémo es que llegaron a sus soluciones (es decir, a sistemas que actualmente se usan en ambientes de produccién). ‘+ Un experto en sistemas operativos debe tener una perspectiva amplia sobre los diferentes sistemas operativos existentes. Alguien que trata o logra recompilar el kernel de Linux, o queDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar obtiene una cettificacién en el uso o administracién de algtin otro sistema, no necesariamente sabe cémo esté funcionando dicho sistema, aimo est construido o cémo puede modificarse para mejorar su rendimiento. ‘+ Deben tomarse en cuenta los avances en otras dreas de las cencias de la computacién, para aplicarlos a los problemas dsicos de los sistemas operativos, 0 para proveerios de nuevas funcionalidades o incluso para proponer nuevos enfoques en su desarrollo (p.ej. técnicas de TA, agentes, etc.) + Alrno tener una referencia préctica sobre el desarrollo de este tipo de sistemas, se limita el avance e innovacién potencial que pudiera lograrse, por falta de conocimiento, No solo hay pocos libros, sino que hay poco interés. + Es necesario crear y difundir una cultura sobre los sistemas operatives para reducir la dependencia tecnolégica del extranjero (cosa dificil a estas alturas, pero no imposible), y mejorar los criterios de consumo de los usuarios finales (épor qué debo cambiar de sistema si ‘el que uso funciona? équé mejoras tiene la nueva versién? équé otras opciones existen?) Por todo lo anterior, decidi llevar a cabo una investigacién que lograra, ante todo, aclarar muchas dudas que creo compartir con muchas personas (sin ir mas lejos, preguntas sobre qué son 0 cémo funcionan los sistemas operatives) con respuestas convincentes que vayan a la médula de la principal interrogante de todo estudiante de ciencias de la computacién: éeémo se disefia y construye un sistema operative? Para ello, me he apoyado en toda a bibliografia a mi alcance y sobre todo en a informacién disponible en Internet (la cual de unos afios para acd se ha incrementado, afortunadamente), asi Como en mi experiencia como desarrollador de software (que es donde hay que lidiar con los sistemas operativos, y donde surgen los retos). El objetivo es organizar y analizar la informadién existente sobre los sistemas operativos, en aspectos tales como: + la conceptualizacién general de este tipo de sistemas, ‘+a integracin de algoritmos y subsistemas que forman parte de ellos, + a concepcién y la implementacién en cédigo de todos sus elementos conceptuales, pues como desarrollador de sistemas sé apreciar la importancia de hacer las cosas para entenderlas, + el aprendizaje de técnicas de un érea de conocimiento, sirve para aplicarlas en la solucién de problemas en otros contextos. No he querido tomar un solo sistema como caso de estudio, pues esto seria limitado, dada la variedad que existe (ademés tratar de adivinar por qué se codificé de cierta manera un programa, o conjeturar sobre las decisiones de disefio del sisterna puede ser poco objetivo). Por el contrario, he tratado de integrar las diversas visiones en tomo a los sistemas operativos para ejemplificar (en lo posible), las ideas y técnicas més representativas aplicadas a estos sistemas (2 nivel de sus componentes y su estructura general) Con base en lo anterior, la propuesta de este trabajo es identificar los principales elementos de los sistemas operatives y analizar las técnicas de disefio e implementacién de estos sistemas, para establecer lineamientos precisos para su concepcién, su disefio y su construccién. Aunque hay varias obras que hablan de oémoDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar hacer un sistema operativo, ninguna de las exposiciones establece una metodologia clara, por lo que es dificil abordar un proyecto de este tipo. La comprensién es basica si se desea analizar 0 construir uno de estos sistemas (hay muchos detalles entre lineas que pueden ser omitidos y que son importantes en la arquitectura del sistema); no sélo se trata de que cada quien haga su sistema operativo (pues esto no tendria mucho sentido), sino de tener los elementos necesarios para que con el advenimiento de nuevas tecnologias, se pueda colaborar en su desarrollo, o por lo menos entender cual es el sentido y capacidades de las nuevas soluciones. Los objetivos concretos de este trabajo son: 1. Exponer los principales conceptos de la teoria de sistemas operativos con un enfoque practico. 2. Analizar diversas arquitecturas de sistemas operatives y sus subsistemas, con el fin de establecer criterios para el disefio de nuevos sistemas operativos, asi como para evaluar los existentes, 3. Proponer algunos modelos de simulacién que integren a los elementos relacionados con el funcionamiento de un sistema operativo. Organizacién del trabajo. Este trabajo esté organizado en tres grandes partes: 1. Conceptos fundamentales de los sistemas operatives y su funcionamiento general. Los primeros dos capitulos exponen los principales concentos relacionados a los sistemas operatives, su evolucién, sus principales componentes y su funcionamiento integral desde una perspectiva general. Esto permitiré comprender que elementos deberdn ser estudiados a detalle, ya limitar el alcance del simulador propuesto. El capitulo 1 presenta los conceptos fundamentales sobre sistemas operativos:Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar - definicién de conceptos de sistemas operativos + evolucién histérica de los SOs y su clasificacién - Identificacién de las principales partes que en general los conforman 1 capitulo 2 presenta el funcionamiento general de los sistemas operativos explorando a los elementos de hardware y software que trabajan en la computadora para que contemos con un sistema de este tipo. El capitulo 3 expone la justificacién del uso de la simulacién para el estudio de los $0, y se analizan algunas de las plataformas de simulacién mas usadas, con el fin de establecer los criterios y elementos de disefio para la simulacidn de los conceptos generales de funcionamiento expuestos en el capitulo 2. Para ello primero se presentan las consideraciones para la simulacion de hardware y sistemas operatives, y un primer prototipo del simulador, el cual fue hecho sin tener un fundamento arquitecténico. I. Sistemas y servicios de administracién de recursos. En la gran mayoria de los libros de sistemas operativos, se dedican 7 6 10 capitulos al estudio de los sistemas de administracién de memoria, procesos, almacenamiento, periféricos, etc. Para no volver a repetir lo que varios libros exponen, decidi que era mejor un enfoque donde se expongan estos sistemas como la definicion de requerimientos que se necesitarén para el simulador. De esta manera, contaremos con un enfoque més practico (pues inclusive se incluyen algunas pruebas de concepto) Los capitulos 4, 5 y 6 abordan el andlisis de los principales componentes de los sistemas operativos, a nivel de sistemas de administracién. En el capitulo 4 se analiza la administracién de memoria En el capitulo 5 se analiza la administracién de procesos. En el capitulo 6 la administracién de dispositivos del sistema. Todo esto brinda una perspectiva de los servicios que por lo general los sistemas operatives ofrecen (y que el usuario espera). LIL Disefio de sistemas operatives, Una vez que contamos con el conocimiento de lo que es y cémo funciona un sistema operativo, y partes que lo integran, llega el momento de aplicarlo. En principio crei que el principal producto seria un simulador, pero de hecho hay un vacio mas importante que llenar: la metodologia de disefio de los sistemas operatives. Por ello, se presentan algunos casos de estudio de varios sistemas operatives para identificar los principales Componentes de las diversas arquitecturas que existen, con el fin de establecer criterios metodolégicos de disefio, 1 capitulo 7 plantea las consideraciones de disefio de sistemas operatives, y expone todo un marco de referencia para su disefio. El capitulo 8 revisa las principales arquitecturas de sistemas operativos y se presentan algunos casos de estudio, que relacionan a sus partes con la disposicién que pueden adoptar en un sistema especifico. Esto sera de utilidad como una paleta de elementos de disefio que el lector Podré aplicar al proceso de disefio.Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar La itima seccién contiene os resultados del trabajo, la experiencia del desarrollo, las conclusiones obtenidas, asi como las perspectivas a futuro del proyecto. Adicionalmente los apéndices contienen varios ejemplos y referencias practicas interesantes, relativas a diversos tépicos como: a. Simulacién de sistemas operativos (modelado del hardware y software que se relaciona al SO). b. Implementacién de servicios del sistema operativo (administracién de la memoria y procesos). . Casos de estudio de implementaciones (un microkernel), ‘Temas relacionados + Sistemas operatives + Sistemas cistribuidos. + Arquitectura de computadoras. + Compiladores y lenguajes de programacién. + Simulacin y modelado. ‘+ Simulacién y emulacin de hardware. + Ingenieria de software. + Arquitectura de software.Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez ValdelamnarDisefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Capitulo 1. Fundamentos de los Sistemas Operativos Todo aquel que desee saber qué ocurriré debe examinar qué ha ocurrido: todas las cosas de este mundo, en cualquier época, tienen su réplica en la antigliedad. Maquiavelo. Para entrar en materia, este primer capitulo esta dedicado a dar respuesta a las preguntas mas comunes relacionadas a los sistemas operatives, tales como: © Qué son los sistemas operativos? ‘+ éCudles son sus principales caracteristicas? ‘+ éCudndo aparecen y para qué? = eCudl ha sido su desarrollo histérico? ‘+ cuales son los principales conceptos que intervienen en su estructura? Se han tratado de incluir todos los aspectos que puedan requerirse para entender estas cuestiones, y para tener las bases para comprender la disertacién de los siguientes capitulos. Adem, puesto que uno de los principales objetivos de este trabajo es el disefo de este tipo de sistemas, es esencial que se comprenda cuales son sus antecedentes, los elementos conceptuales a manejar y la interaccién entre ellos, para asi pasar a cuestiones més especificas. 1.1 ¢Qué es un sistema operativo? ‘Aunque en las Uitimas décadas se han hecho propuestas en cuanto a nuevos tipos de computadoras, el hecho es que sin el software (0 programas, que son conjuntos de instrucciones gue una maquina ejecuta) una computadora es solo un ingenio electrénico incapaz de realizar tareas ttiles. Con el software, una computadora puede almacenar, procesar y recuperar informacién. El software para computadoras puede clasificarse en general como: + Programas de sistema, que controlan la operacisn de la computadora en si + Programas de aplicacién, os cuales definen la forma en que los recursos de la computadora se emplean para resolver los problemas de computacién de los usuarios (compiladores, sisterias de bases de datos, juegos de video y programas para negocios).Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar ‘Usuarios Figura 1.1 Vista de los programas de sistema y de aplicacién. El elemento fundamental de todos los programas de sistema es el Sistema Operativo (SO), que controla todos los recursos de la computadora y proporciona la base sobre la cual pueden escribirse y ejecutarse los programas de aplicacién. | =? ak Mowe te - ~a$ / I ee Trai esa My oa. saad Provesstor Memoria Figura 1.2 El SO administra los recursos de hardware y software de la computadora, y provee un medio estable y consistente donde las aplicaciones puedan usar el hardware. Puesto que hay una gran variedad de puntos de vista respecto a lo que es un sistema operativo, es prudente presentar algunas de las definiciones mas representativas para empezar a comprender la amplitud de funciones de este tipo de sistemas. 4.1.1. Definiciones ‘A continuacién se presenta un conjunto de definiciones que contienen diferentes perspectivas de lo que es (0 deberia ser) un sistema operativo (SO).Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar I. Un SO es el programa que se ejecuta en todo instante en la computadora. TI, Un SO es un programa que acta como intermediario entre el usuario y el hardware de la computadora. Su propésito es proveer un ambiente en el cual el usuario pueda ejecutar programas. IIL. Un SO es un conjunto de programas de control del sistema de cémputo, cuyas funciones son: - Administracién y control de los dispositivos del sistema de cémputo. = Solucién a problemas tales como el tiempo de procesador, espacio en memoria, espacio para almacenamiento de archivos, dispositivos E/S, etc. + Ambiente de ejecucién de los programas. Un programa que controla la ejecucién de los programas del usuario previniendo errores y usos indebidos de la computador. + Interfaz entre: = Programas y hardware (llemadas al SO). = Programador-usuario (lenguaje). Proveer cémputo a bajo costo al compartir recursos e informacién. IV. Un SO es una coleccién integrada de rutinas que sirven para el secuenciamiento y procesamiento de programas por medio de una computadora. Un sistema operative puede prover varios servicios, como el alojamiento de recursos, planificacién, control de la entrada/salida y administracién de datos. Aunque los sistemas operatives son software predominantemente, implementaciones parciales o totales pueden ser hechas en forma de firmware (software escrito en ROM). \. Un sistema de cémputo puede ser definido en términos de varias funciones de supervisién y control que provee para los procesos (programas en ejecucién) creados por el usuario, tales como: 1. Crear y quitar procesos. 2. Controlar el progreso de los procesos (p.ej. asegurando que no existan bloqueos entre los procesos activos). 3. Actuar en condiciones excepcionales que ocurran durante la ejecucion de un proceso (errores aritméticos, de direccionamiento). 4, Asignar recursos de hardware a los procesos. 5. Dar acceso a los recursos de software (archivo, compiladores, etc.). 6. Proveer proteccién, control de acceso y seguridad a la informacién. 7. Proveer comunicacién entre procesos y sincronizacion. Estas funciones deben ser provistas por el sistema ya que no siempre pueden ser manejadas adecuadamente por los mismos procesos. El software encargado de asistir al hardware en estas funciones es conocido como el sistema operative. ‘Todas estas definiciones son complementarias, y en resumen, se puede decir que los Sistemas Operatives son un conjunto de programas que crean la interfaz del hardware con el usuario, y gue tienen como funciones primordiales:Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar ‘* Administrar el hardware. Se refiere al hecho de administrar de una forma més eficiente los recursos de la maquina. ‘+ Facilitar el trabajo al usuario. Permite una comunicacién con los dispositives de la méquina. + Controlar la efecucién de programas y proveer los servicios necesarios para hacerlo. ‘A continuacién veremos las caracteristicas principales de los sistemas operativos. 4.1.2. Caracteristicas principales ‘Algunas de las principales caracteristicas generales de los sistemas operativos actuales son: a. Concurrencia. Es la existencia de varies actividades simulténeas (0 paralelas). Algunos ejemplos son la coexistenda en memoria de varias aplicaciones del usuario y la ejecucién simultanea de operaciones de E/S y procesos de cémputo. La concurrencia plantea problemas tales como el cambio de una actividad a otra (switching), la proteccién de una actividad contra los efectos de otra y la sincronizacién de actividades que son mutuamente dependientes. b. Compartir recursos 0 informacién entre las actividades concurrentes. Algunas de las razones son: 1) Costos. A causa de que proveer con equipo suficiente a varios usuarios resulta muy caro. ii) _Reutilizacién. Utilizacién de de programas o rutinas ya existentes para desarrollar nuevas aplicaciones. iii) Compartir datos de una misma base de datos para diferentes programas. iv) Evitar la redundancia de utilizar copias individuales de un programa en vez de compartir una sola c. Almacenamiento a largo plazo de programas ¢ informacién. 4. Un sistema operativo debe ser determinista, en el sentido de que al correr un programa con los mismos datos en diferentes dias, debe obtenerse el mismo resultado. Por otra parte debe responder a eventos que ocurren en orden impredecible. Tales eventos pueden ser requerimientos de recursos, errores de tiempo de ejecucién en los programas e interrupciones de los dispositivos periféricos. Por lo tanto e/ SO debe ser escrito para manejar cualquier secuencia de eventos probable. e. Multiplexado. Una técnica en la que el tiempo es dividido en varios intervalos donde un recurso es asignado a un proceso durante cada intervalo. ‘Algunas otras caracteristicas deseables son las siguientes: Algunos de los criterios a tomar en cuenta son: a) Tiempo minimo entre procesos.Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar b) Tiempo de respuesta (en sistemas multiusuario) ©) Utilizacién de recursos. d) Libre de errores. Fécil mantenimiento. Debe ser posible mantener un SO (mejoréndolo o corrigiendo errores) sin emplear un efercito de programadores, por lo que el sistema debe ser modular, con interfaces claras y bien definidas entre los médulos, y contar con una documentacién completa Tamajio. EI espacio utilizado para cargar en memoria al sistema operativo, es desperdiciado en lo que respecta a procesos productivos. Si el sistema es grande, se tiene la desventaja de que sea més susceptible a errores, y tome més tiempo de codificacién que uno pequefio. Interoperabilidad. Es la habilidad del sistema de faciltar intercambio de informacién entre los componentes heterogéneos en el sisterna ‘Transparencia. Es la propiedad que permite a los usuarios ver al conjunto de maquinas en las que esta trabajando como una sola maquina. ‘Autonomia. Es la independencia de los sistemas operativos con respecto al hardware, lo Que permite que el sistema trabaje con unidades auténomas. En la siguiente seccién se revisan los principales conceptos relacionados a los sistemas operativos, los cuales serén explorados con mas detalle en capitulos subsecuentes. 1.2 Principales conceptos de los Sistemas Operativos® Basicamente el sistema operativo “ensefia a la computadora como comportarse”, es decir, como controlar y coordinar su procesador, la memoria, los dispositivos periféricos y como comunicarse con los usuarios. olcacionos Daniisteckinge 16 Maneiadores de depesivo ‘Adminstacan dels meron ‘Aémishasiin ge CPL. bree Figura 1.3 Soporte de software necesario para aprovechar los recursos del hardware. © Obras consultadas: (1.11] [1.12]Disefio y sizulacion de sistemas opes vos ~ Eugenio Jacobo Hemindez Valdelamar La idea de crear un sistema tan grande y complejo como un SO, solo puede manejarse partiéndolo en pequefios médulos, los cuales poseen una funcién bien definida en el sistema, con sus Correspondientes entradas y salidas. Hardware Ejemplos de servicios de SO ‘Abstraccién del usuario ‘Administracién de Procesos, Procesador Planificacién (scheduling), Excepciones, Proceso Proteccién, Sincronizacién ‘Administracién, Proteccién, Memoria Espacio de direcciones Memoria Virtual Concurrencia con el CPU, Terminal, Mouse, Impresora, Dispositivos de €/S " J " Nspostives de E/ Manejo de Interrupciones (Uamadas al sistema) Sistema de archivos ‘Administracién, Persistencia Archivos Llamadas al sistema, llamado Seguridad en red remoto de procedimientos (RPC), Sistemas distribuid "stems cistnbuldos Sistema de archivos distribuido _| Acceso transparente de archivos (Transparent file sharing) Tabla I. Recursos de la arquitectura, administracién del sistema operativo y abstracciones del usuario. En las siguientes secciones se define el objetivo y actividades de cada uno de esos médulos (el criterio de seleccién de los médulos expuestos es que en su mayoria aparecen de forma constante en casi cualquier sistema operativo). 4.2.1 Administracién de procesos Uno de los conceptos fundamentales en casi todo SO es el de proceso. Como se menciond anteriormente, un proceso es un programa en ejecucion, y el SO debe encargarse de proveer los medios para controlar dicha ejecucién. De ahi nace el concepto de administracién de procesos. EI microprocesador no hace las cosas por si solo; el sistema operativo es el que determina que proceso se debe ejecutar y cuanto tiempo debe estar ejecutandose. A todo esto se le denomina administracién de procesos. El SO es responsable de las siguientes actividades relacionadas con la administracién de procesos: ‘+ Creacién y borrado de procesos del sistema y el usuario. + La suspensién y rehabilitacién de procesos. ‘+ Proveer mecanismos para la sincronizacién de procesos. + Proveer mecanismos para la comunicacién entre procesos (IPC) ‘+ Proveer mecanismos para el manejo de bloqueos (deadlocks).Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar 1.2.2. Administracién de memoria Para que los programas se ejecuten, deben ser almacenados en la memoria de la maquina, por lo que el SO debe ser capaz de interactuar con la memoria primaria de la computadora, asi como con las abstracciones que el sistema realice con ella (p.e). estructuras de datos) para gestionar los datos que van entrando y saliendo de la memoria de la computadora (fig. 1.4). cons |_| Figura 1.4 Esquema de los diferentes tipos de memoria en un sistema de cémputo, El SO es responsable de las siguientes actividades relacionadas con la admit memoria istracién de ‘+ Mantener un seguimiento de que partes de la memoria estén uso y por quién. + Decidir que procesos serdn cargados en memoria cuando exista espacio disponible. ‘+ Asignar y quitar espacio en memoria como sea requerido, Una de las abstracciones mas importantes relacionadas con la administracién de la memoria, es el concepto de memoria virtual. La administracién de la memoria virtual se encarga de mantener el mapeo de la memoria virtual y fisica, decidir en el tamario de la memoria asignada a los procesos y reforzar la politica de reemplazo. 1.2.3 La gestién de la integridad Hay que tener en cuenta que cualquier programa puede, aunque no sea deseable, hacer mencién a recursos, direcciones y otros accesos indebidos; si dichos accesos no son controlados, se produciria un error que daria como origen algo que no nos podriamos imaginar (reinicio de la maquina, bloqueo, etc.) Para evitar todos estos problemas, los sistemas operatives tienen distintos niveles de seguridad: 2. En la memoria: Hemos dicho que los programas se cargan en la memoria, pero imaginemos, que un programa hace una escritura en una zona de memoria que es de otro programa, para evitar esto el sistema operativo realiza una gestién de la memoria entre los usuarios. . En ef uso del CPU: Los programas se dividen en procesos que se efecutan en el rmicroprocesador (CPU), pero si varios procesos intentaran ejecutarse a la vez se produciria un 13Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar efecto imprevisible, Para ello el sistema operativo controla la ejecucién de los procesos, la duracién de cada uno de ellos y cuando deben entrar o salir de la ejecucisn. c. En el uso de las entradas y salidas (E/S): En realidad no es que el sistema operativo controle la E/S aunque si lo haga cuando es necesario, lo que ocurre es que si hay un proceso ejecuténdose en la cpu y va a imprimir en la impresora algo, el sistema operativo, bloquea el uso de la impresora hasta que el proceso no termine con ella para que no haya otto proceso enviando informacién a la impresora por que si fuera asf entonces provocaria un conflcto en la impresora, y al mismo tiempo saca del procesador el proceso que esta imprimiendo, por que sino los demés procesos tendrian que esperar a que el proceso terminara de imprimir para seguir con el CPU y entonces el CPU estaria bloqueado perdiendo tiempo inctimente, por que el proceso consume el tiempo del procesador, cuando en realidad no hace nada con él pues est imprimiendo. 1.2.4 Administracién de dispositivos Puesto que las configuraciones de hardware de las computadoras varian segiin las necesidades y desarrollo tecnoldgico, un area de constante desarrollo es la construccién de nuevos dispositivos periféricos que permitan a las computadoras expandir sus capacidades basicas. Para ello, es necesario que un SO cuente con subsistemas que permitan acceder a tales dispositivos. Dichos subsistemas son los siguientes: 1. Administracién del sistema de E/S (1/0). Puesto que uno de los propésitos del SO es hacer transparente las peculiaridades del hardware al usuario, se tiene un sistema de E/S que consiste de: * Una interfaz general dispositivo-controlador (device-driver). ‘+ Manejadores para dispositives especificos de hardware. 2. Manejadores de dispositivos (device drivers): Los manejadores son piezas de cédigo especiales que se encargan de la comunicacién de todos los periféricos de la computadora (como terminales, impresoras, discos, etc.) Debe existir un manejador especial para cada diferente tipo de dispositive conectado, y puesto que hay tantas posibilidades y cada dia aparecen nuevos periféricos, no se pueden construir directamente en el kernel. Es necesario hacerlos una parte diferente que pueda ser sustituida 0 removida de la computadora. 1.2.5 Almacenamiento secundario Tal vez los dispositivos periféricos més usados, sean los de almacenamiento secundario (Cintas, discos, etc.). Como la informacién se ha vuelto un bien vital para los usuarios, se requiere que los sistemas operativos provean servidos que hagan seguro, fécil y transparente el manejo y almacenamiento de informacién. Los servicios implementados por el SO son los siguientes: a. Administracién de almacenamiento secundario. £1 SO es responsable de las siguientes actividades relacionadas con la administracién de discos: ‘+ Manejo del espacio libre.Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar ‘+ Distribucién de almacenamiento. + Organizacién del disco. b. Administracién de archivos. El SO es responsable de las siguientes actividades relacionadas con la administracién y organizacién de archivos: + Lacreacién y borrado, de archivos y directorios. ‘+ Bloqueo y proteccién de archivos y directorios. ‘+ Soporte de operaciones primitivas para la manipulacién de archivos y directorios. ‘+ Elmapeo de archivos en almacenamiento secundario, ‘+ Elrespaldo de archivos en un medio estable de almacenamiento. La principal abstraccién que provee el SO para el manejo del almacenamiento secundario es el sistema de archivos, el cual permite ordenar los datos en una forma estructurade, facil de recordar y manejar (p.ej. archivos de tamafio variable, directorio, etc. EI sistema de archivos trabaja sobre los manejadores de dispositivs para proveer una interfaz abstracta con los diferentes manejadores. Define la forma de almacenar informacién en dispositivos de almacenamiento, por lo que no es necesario aprender un nuevo método de almacenamiento para cada dispositive posible. 4.2.6 Transmisién de datos e informacién ‘Ademés de almacenar informacién, otra necesidad imperiosa es la de transmitirla. Cuando las computadoras cuentan con los dispositivos necesarios, pueden ser conectadas entre si, formando redes. Nuevamente el SO debe ofrecer la capacidad de conectarse a estas redes, y ‘ransmitir y recibir informacién de forma segura. Para ello se necesitan a. Servicios de Comunicacién en Red (networking). Se refiere a la conexién de miltiples procesadores por medio de una red, que puede ser configurada de diferentes maneras, y debe ‘tomar en cuenta estrategias de conexién y ruteo, asi como casos de contencién y seguridad, ademas de dar soporte a varios protocolos y medios de comunicacién. b. Proteccién del sistema. Se refiere a mecanismos para controlar el acceso de programas, procesos o usuarios a los recursos definidos por un sistema de cémputo. ©. Programas Auxiliares. Estos programas se encargan de ayudar al SO a llevar a cabo sus tareas. Estos programas pueden encargarse de controlar comunicaciones, seguridad, etc. Algunos son visibles como el programa de autentificacién de usuarios (login), pero muchos otros trabajan escondidos en el trasfondo (en algunos sistemas son llamados demonios). 1.2.7 Nucleo del sistema (Kernel) Una abstraccién fundamental hecha con base en los conceptos anteriores, es la de organizar todos estos médulos de forma que pueda contarse con un mayor o menor nuimero de servicios por parte del SO. Tal abstraccién es llamada niicleo o kernel del sistema operativ.Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar El kernel (0 niticleo) es la parte del sisterna que en realidad se encarga de los aspectos mis basicos de la funcionalidad, principalmente con la forma en que la computadora se comportaré. Comiinmente, el kernel estableceré las polticas de trabajo (tarea simple o multitarea; métodos de planificacién), como manejar a los componentes basicos (p.ej. politicas de manejo de memoria como el uso de la memoria virtual), las medidas de seguridad basica y como iniciar, comunicarse y apagar todos los demas componentes. ‘Toda esta gestién la realiza para atender al funcionamiento y peticiones de los trabajos que se ejecutan en el sistema, El nucleo normalmente representa sélo una pequefia parte de lo que por lo general se piensa que es todo el sistema operativo, pero es el codigo que mas se utiliza. Por esta razén ef nicleo reside por lo regular en la memoria principal, mientras que otras partes del sistema operativo son cargadas en la memoria principal slo cuando se necesitan. n con el usuario® 4.2.8 Comunicai Una vez establecidos los conceptos relatives al control de los recursos de hardware y software, Podemos hablar de la forma en que una computadora con sistema operativo se comunica con el usuario. a. Interfaz de usuario. La Interfaz de usuario es la parte del sistema que provee una forma en que la computadora capte y reaccione a las acciones del usuario, y transmita la informacién que el usuario produce. Es el componente que se encarga de traducir los datos binarios en numeros y caracteres en la pantalla, o interpretar los cédigos binarios del teclado, y si se trata de una interfaz grafica de usuario (GUI), se encarga de dibujar las ventanas y otros objetos en la pantalla. Nétese que una computadora puede tener varias interfaces de usuario para adaptarse a diferentes modelos de terminales o preferencias del usuario, b. Shells - Sistema interprete de comandos (Command Language Interpreter, CLI). El SO esta disefiado para trabajar en conjunto con otros programas, y no se pretende que sea accedido directamente por el usuario, Asi que por lo menos se requiere un programa que sirva de interfaz entre el usuario y el sistema para permitir el uso de la computadora. La mayor parte de los sistemas operativos cuentan con uno 0 mas de estos programas (los cuales solo reciben comandos y los traducen en instrucciones del SO). Varias ordenes le son dadas al SO por medio de sentencias de control, Cuando un nuevo trabajo comienza en un sistema batch, o cuando un Usuario accede en un sistema de tiempo compartido, un programa que lee e interpreta dichas ordenes es ejecutado inmediatamente, Se le llama también intérprete de tarjetas de control, intérprete de comandos en linea, el shell (en UNIX), etc. Su funcién es bastante simple: obtener el siguiente comando y efecutarto. © Obras consultadas: (1.29]Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar tena insmveceres Figura 1.5 Niveles de interaccién de un shell Los SOs se distinguen frecuentemente en el drea de interpretacién de comandos, por interpretes mas amigables que hacen més agradable el sistema a los usuarios, Un ejemplo es el intérprete de Mac, que es un sistema basado en ventanas que es exclusivamente activado en Giertas regiones (iconos) por el ratén, c. Interfaz grafica de usuario (GUIs -Graphical User Interfaces). Las GUIs despliegan objetos aréficos en la pantalla (imagenes, iconos, botones, etc.) y el usuario interactua con ellos usando lun dispositive apuntador (por lo general un ratén (mouse)). Las interfaces gréficas modernas Usan una "metéfora de escritorio” en las que areas conocidas como ventanas, contienen actividades de trabajo, como hojas de papel sobre un escritorio real, Las GUIs hacen uso extensivo de los gréficos por computadora para organizar el drea de trabajo del usuario, y presentan formas intuitivas para realizar diversas tareas. En 1968 Doug Engelbart del Stanford Research Center's Augmentation Research Center, patrocinado por la Agencia de Proyectos de Investigacién Avanzados del Departamento de Defensa (ARPA), instrument6. el primer sistema de ventanas (windowing system). En 1970, investigadores del Centro de Investigacién de Palo Alto (XEROX PARC) disefiaron la primera computadora con interfaz gréfica (Alto Computer)Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar @ ©) Figura 1.6 Ejemplos de interfaz grafica de usuario: (a) el sistema NeXT; (b) Mac OS X. Por lo anterior, se puede decir que aunque el SO es una parte muy importante del sistema de computo, este queda fuera de la vista de los usuarios, los cuales lo notan de forma indirecta por medio de las capacidades que el SO prove y las cosas que permite y no permite hacer, cuando lo acceden por medio de otros programas como los shells 0 las GUIs, que son los que comprenden e interpretan las acciones que el usuario quiere realizar. Para entender cémo es que aparecieron este tipo de sistemas, revisaremos la historia de la computacién con Ia intencién de entender las motivaciones que condujeron al desarrollo de los sistemas operativos. 1.3. Desarrollo histérico de los Sistemas Operativos® Para tener una perspectiva completa de los sistemas operativos, es importante revisar su historia, la cual es paralela al desarrollo del hardware de las computadoras, pues los nuevos vances requerian de nuevas soluciones. Basado en algunas referencias relativas a la historia y evolucin de las computadoras, se ha desarrollado la siguiente cronologia (fig. 1.7) la cual integra a las generaciones de computadoras digitales y a los sistemas operativos. En ella se han tratado de indir los principales paradigmas de ambas reas, Por convencién, la primera generacién inicia con las primeras computadoras electrénicas, en lugar de las méquinas mecénicas y electromecénicas que les antecedieron. Cabe mencionar que de todas las referencias consultadas, no hay un consenso en cuanto a los periodos de tiempo que cada generacién cubre, 0 incluso a los criterios que se usan para definirlas. Un criterio interesante se basa en los cambios en la tecnologia de implementacién dominante, que permiten crear nuevas computadoras. Sin embargo, es posible obtener nuevas configuraciones con la tecnologia disponible, creando arreglos complejos de procesadores (que ademas implica desarrollar tecnologias de conectividad y sincronizacién). © Obras consultadas: (1.1) (1.2) [1.3] [1.4] 1.5] [1.6] (1.7) (1.8) (1.9) (1.10) 18Disefio y simulacion de sistemas operatives ~ Eugenio Jacobo Hemsindez Valdelarmar Figura 1.7 Cronologia del desarrollo de las computadoras y los sistemas operativos.Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar En las siguientes secciones se explora el desarrollo histérico de los sistemas operativos, con el fin de tener una idea de como han ido evolucionando, y para apreciar un poco mas “los ujos” que hoy disfrutamos en nuestras computadoras. Aunque los primeros sistemas ahora pueden ser (© parecer) obsoletos, no deja de ser interesante su andlisis para comprender las tendencias actuales en su desarrollo. 1.3.4 Enel principio.. Las primeras computadoras de fines de los 1940s no tenian sistema operative. En un principio solo existia el hardware de la computadora. Las primeras computadoras eran (fisicamente) grandes maquinas que se operaban desde una consola. El programador escribia un programa y luego lo controlaba directamente. En primer lugar, el programa se cargaba manualmente en la memoria, desde los interruptores del tablero frontal, desde una cinta de papel o desde tarjetas perforadas. Luego se pulsaban los botones adecuados para establecer la direccién de inicio y comenzar la ejecucién del programa. Mientras este se ejecutaba, el programador-operador lo podia superviser observando las luces en la consola, Si se descubrian errores, el programador podia detener el programa, examinar el Contenido de la memoria y los registros y depurar el programa directamente desde la consola. La salida del programa se imprimia, 0 se perforaba en cintas de papel o tarjetas para su impresién posterior. Un aspecto importante de ese entomo era su naturaleza interactiva directa, El programador también era el operador del sistema de cémputo (figura 1.8). Al mismo tiempo, el problema matematico a resolver, se mezclaba con los problemas fisicos de la computadora. El trabajo de los operadores humanos, quienes planificaban los trabajos listos para ejecutar y supervisaban el uso de los recursos de la computadora, fue una de las primeras ocupaciones en ser automatizada, ‘Tethyp en gomsion C_] SE anion Figura 1.8 Esquema de operacién de las primeras computadoras. Estas computadoras eran tan caras, que el principal objetivo de un sistema operativo era hacer al hardware tan eficiente como fuera posible. Ademés, los programadores producian su propio 20Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Cédigo objeto para los programas, incluyendo todas las instrucciones para entrada de datos de las tarjetas o cinta de papel y salida de resultados a impresoras o cinta magnetic, Un programa (0 trabajo) era cargado y ejecutado a la vez hasta su término o detenido a causa de un error; el sistema estaba ocioso hasta que el siguiente programa fuera cargado y ejecutado. Durante los 1950s, los cargadores, rutinas esténdar de entrada/salida (E/S), ligadores, ensambladores y compiladores fueron introducides, junto con el concepto de archivo, asi que el cédigo de programa o conjuntos de datos podian ser referidos por medio de nombres de archivos. Lotes de archivos de programas eran cargados de una sola vez (a través de lectoras de tarjetas), y compartian el CPU y la memoria primaria: cuando un programa esperaba por el término de la lenta E/S, era suspendido de forma que otro programa pudiera usar el CPU (multi programacién), En los anales de la histori de la computacién, 1956 es el afio en que aparece el primer sistema operative, ciseiado pare la 18M 704 (por Bob Patrick (General Motors) y Owen Mock (North American Aviation)), llamado GM-NAA I/O, y permitia el procesamiento por lotes (una forma simple de combinar comandos existentes en nuevos comandos). En la siguiente seccién se explica a detalle la operacién del procesamiento por lotes. 4.3.2 Procesamiento por lotes y monitores Los Sistemas Operativos por lotes, procesan una gran cantidad de trabajos con poca o ninguna interaccién entre los usuarios y los programas en ejecucién. Se renen todos los trabajos comunes para realizarlos al mismo tiempo, evitando la espera de dos 0 més trabajos como sucede en el procesamiento en serie. Estos sistemas son de los més tradicionales y antiguos, y fueron introducidos alrededor de 1956 para aumentar la capacidad de procesamiento de los programas. Un sistema de lotes es aque! cuyos trabajos (Jobs) son reunidos con las instrucciones ecesarias para permitirles ser procesados sin intervencién de un operador. El monitor residente (0 monitor), es el software del sistema que es responsable de interpretar y ejecutar las instrucciones en los trabajos por lotes. Cuando el monitor comenzaba un trabajo, cedia el control completo de la computadora al trabajo, el cual controlaba la computadora hasta su término (figura 1.9) 2Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar ___ Vecior de interrupciones Intérprete de JCL Cargador de programas Manejedores de dispositives ES ‘Memorias intormedias (buferes) Rtinas de tratamiento de errares Monitor residente Figura 1.9 Esquema basico de la memoria de una computadora con procesamiento por lotes (monitor residente). Un ejemplo de varios trabajos en lote podria verse asi OB user + identificar al usuarie SFORTRAN } cargar el compilader de FORTRAN source program } tarjetas con el programa fuer SLOAD ; cargar el prog omp! lado SRON : gata cards : SFOs ; $908 user_spec : + cargar aplicacién cutar la aplicacién i fin del trabajo Por lo general se usaban cintas magnéticas o tambores para almacenar los datos intermedios y programas compilados. Las ventajas y desventajas de este tipo de sistemas son: 1. Ventajas > mueve mucho del trabajo del operador a la computadora > incrementa el desempefio, puesto que es posible para un trabajo comenzar tan pronto como el anterior termina 2. Desventajas > depuracién complicada de programas > debido al esquema de proteccién, un trabajo del lote puede afectar a los demas trabajos pendientes (p.ej. a causa de la lectura de demasiadas tarjetas, etc.) > un trabajo puede corromper al monitor, afectando también a los trabajos pendientes > un trabajo puede entrar en un ciclo infinito Como se mencioné, una de las mayores carencias de los sistemas por lotes era que no existia Un esquema de proteccién para prevenir que algin trabajo afecte adversamente a otros, La solucién a esto era un simple esquema de proteccién, donde cierta memoria (p.ej. donde reside 22Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar el monitor) era restringida a los programas de usuario. Esto prevenia que los programas de Usuario corrompieran al monitor. Para evitar que los programas de usuario leyeran demasiadas (0 pocas) tarjetas, el hardware era cambiado para permitir ala computadora operar en uno de dos modos: uno para el monitor y Uno para los programas de usuario. La entrada/salida (E/S) podria solo ser reaizada en modo de monitor, asi que las peticiones de E/S de los programas de usuario eran pasadas al monitor. De esta manera, el monitor podria evtar que un trabajo no leyera su tarjeta de fin de trabajo ($£03), Para prevenir un ciclo infinito, un temporizador (timer) fue agregado al sistema y la tarjeta $108 fue modificada para que el tiempo maximo de ejecucién de un trabajo fuera enviado al monitor. La computadora podria interrumpir el trabajo y regresar el control al monitor si se excedia este tiempo. Cuando estos sistemas son bien planeados, pueden tener un tiempo de ejecucién muy alto, porque el procesador es mejor utlizado y los Sistemas Operativos pueden ser simples, debido a la naturaleza secuencial de la ejecucién de los trabajos. Algunos ejemplos de Sistemas Operatives por lotes exitosos son el SCOPE, de! DC6600, el cual esté orientado a procesamiento cientifico pesado, y el EXEC II para el UNIVAC 1107, orientado a procesamiento académico, 1.3.3. Sistemas de operacién simultanea de periféricos en linea Una dificutad con los senillos sistemas de lotes es que la computadora atin necesitaba leer el bloque de tarjetas antes de comenzar a ejecutar un trabajo. Esto significa que el CPU estaria ocioso durante estas operaciones relativamente lentas. Procesamiento serial a a ‘Pracesamiento en lotes ‘Procesamiento tiempo compartide pt p3 tiempo ——> Typos Bisisos de Procesamiento Figura 1.10 Esquemas biisicos de procesamiento, Nétese como el tiempo desperdiciado ha ido disminuyendo 23Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Puesto que es mas répida la lectura de una cinta magnética que un bloque de tarjetas, se volvié. comin para los centros de cémputo tener una o mas computadoras menos potentes en complemento a su computadora principal. Las computadoras pequefias eran usadas para leer y cargar las tarjetas a las cintas, por lo que la cinta podia contener varios trabajos en lote, Esta cinta era entonces cargada en la computadora principal y los trabajos de la cinta eran ejecutados. La salida de los trabajos podia ser escrita a otra cinta que era retirada y cargada en luna computadora de menor capacidad para producir cualquier salida deseada (p.ej. impresiones). Una extensién légica del temporizador en el sistema por lotes, fue tener un temporizador que pudiera permitir a los trabajos ejecutarse solo por un corto periodo de tiempo antes de interrumpirlos para que el monitor pudiera iniciar alguna operacién de E/S. Puesto que la operacién de E/S podria proceder mientras el CPU se ocupaba en un programa de usuario (realizar E/S y cdlculos en paralelo), fue posible que la computadora leyera tarjetas a las Cintas, tambores o discos y escribir la salida a una cinta mientras seguia procesando programas. Este proceso es llamado SPOOLing (Simultaneous Peripheral Operation OnLine). Los sistemas por lotes Spooling (Spooling Batch Systems) fueron los primeros (y més simples) sistemas de mmuttiprogramacién. Una ventaja de los sistemas de spooling era que la salida estaba disponible tan pronto como el trabajo se completara, en vez de tenerla cuando todos los trabajos del lote se completaran. 4.3.4. Sistemas de Multiprogramacién Cuando méquinas con mayor cantidad de memoria estuvieron disponibles, fue posible extender la idea de multiprogramacién como se hizo en los sistemas de spooling al crear sistemas capaces de cargar varios trabajos en memoria de una sola vez y cidarlos en el mismo orden, trabajando en cada uno por un periodo especifico de tiempo. Ex) Usuero Figura 1.11 Esquema de sistema de multiprogramacién (o multitarea), donde varias lareas son ejecutadas simulténeamente.Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar En este punto, el monitor crece hasta el punto de parecer un sistema operativo moderno, el cual es responsable de: ‘+ iniciar trabajos de usuario + operaciones de spooling ‘+ E/S para trabajos de usuario ‘+ switcheo entre trabajos de usuario ‘+ asegurar la proteccién adecuada mientras realiza las tareas anteriores Como un simple y comiin ejemplo, considérese una maquina que puede correr dos trabajos a la vez. Incluso, supongamos que un trabajo es de E/S intensiva y que el otro usa el CPU intensivamente. Una forma para el monitor de obtener tiempo de CPU entre estos trabajos podria ser dividir el tiempo equitativamente entre ellos. Sin embargo, el monitor podria estar ocioso gran parte del tiempo durante la ejecucién del proceso de E/S. Una buena solucién en este caso es permitir al trabajo del CPU (background job) ejecutarse hasta que el trabajo de E/S (foreground job) necesite tiempo de CPU, momento en el cual el monitor le permite ejecutarse, y cuando requiera de nuevo realizar sus operaciones de E/S, se devuelve el control al trabajo anterior. Los Sistemas Operativos de multiprogramacién (0 de multitarea) se distinguen por sus habilidades para poder soportar la ejecucién de dos 0 més trabajos activos (que se estan ejecutado) al mismo tiempo. Esto trae como resultado que el CPU siempre tenga alguna tarea que ejecutar, aprovechando al maximo su utilizacién, Sin mulnprogramacién Con madbipreey Figura 1.12 Esquema de ejecucién de dos procesos con y sin multiprogramacién. Su objetivo es tener a varias tareas en la memoria principal, de manera que cada uno esté usando el procesador, o un procesador distinto, es decir, involucra maquinas con mas de una CPU. Sistemas Operatives como UNIX, Windows 95, Windows 98, Windows NT, MAC-OS, OS/2, soportan la multitarea, * Sistemas de tiempo compartido (Timesharing) En los tiempos en los que no se disponia de un sistema operative, el programador tenia acceso completo a la maquina. Al desarrollarse hardware y software para crear monitores, sistemas de lotes y multiprogramacién, la separacién entre el usuario y la computadora de volvié mas pronunciada. 25Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Uno de los problemas més comunes era que los usuarios y los progremadores en particular, tardaban en tener acceso a la méquina (sobre todo en los esquemas de lotes). Tal cuestidn ‘rato de solucionarse por medio de un esquema llamado de tiempo compartido (timesharing/timesicing). La idea de multiprogramacién fue extendida para permitir que varias terminales fueran conectadas a la computadora, y que a cada terminal en uso se le asociaran uno o mas trabajos en la computadora. El SO era entonces responsable de intercalar (switching) los trabajos (también llamados procesos) de manera que se favoreciera la interaccidn con el usuario. Si el Cambio de contexto (context-switches) ocurtia lo suficientemente répido y con la suficiente frecuencia, el usuario tenia la impresién de tener acceso directo a la computadora, ‘A los procesos interactivos se les da una mayor prioridad, asi que cuando una E/S es. requerida (p.e}. una tecla presionada), el control del CPU le es dado al proceso asociado, asi que puede procesario. Esto es instrumentado mediante el uso de una interrupcién que causa que la computadora se de cuenta que un evento de &/S ha ocurrido. Debe mencionarse que existen varios tipos de sistemas de tiempo compartido. Una clase es representada por computadoras como las VAX/VMS y las estaciones de trabajo UNIX. En estas computadoras, procesos enteros se encuentran en memoria, y la computadora intercala la ejecucién entre ellos, En otros tipos de sistemas, como los de reservacién de vuelos, una sola aplicacién puede hacer la distribucién de tiempo entre las terminales. De esta forma no se necesita ejecutar un programa diferente asociado a cada terminal. Los Sistemas Operativos de tiempo compartido permiten simular que el sistema y sus recursos son todos para cada usuario. El usuario hace una peticién a la computadora, esta la procesa tan pronto como le es posible, y la respuesta aparecera en la terminal del usuario en Un tiempo muy corto, dando la impresién al usuario de tener al sistema bajo su control exclusive, Figura 1.13 Esquema de un sistema de tiempo compartido. Los principales recursos del sistema, el procesador, la memoria, dispositivos de £/S, son continuamente utilizados entre los diversos usuarios, dando a cada usuario la ilusién de que tiene el sistema dedicado para si mismo. Esto trae como consecuencia una gran carga de trabajo al sistema operativo, principalmente en la administracién de la memoria principal y secundaria. 26Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Ejemplos de sistemas operativos de tiempo compartido son Multics, OS/360 y DEC-10. Sistemas de Tiempo Real® Para empezar, un sistema de tiempo real es aquel sistema informético en el que el desemperio del sistema no sélo depende de los resultados Idgicos de los algoritmos, sino que ‘también depende del momento en el que estos se producen. Una computadora de tiempo reaf es aquella que ejecuta programas que estan garantizados en poser un desempefio superior en las tareas que desarrollan. Por ejemplo los sistemas de guia de misiles y equipo de monitoreo médico. Las computadoras dedicadas son computadoras de propésito especial que son usadas para realizar solo una o mas tareas. Comtinmente estas son computadoras de tiempo real que incluyen aplicaciones de control (misiles, inyeccién electrénica de gasolina, control automatico de trenes, etc.).. Los sistemas operativs de este tipo de computadoras estén severamente restringidos por requerimientos de tiempo. Figura 1.14 Esquema de un sistema de control, en donde deben ser aceptados y procesados gran cantidad de sucesos. Los Sistemas Operativos de tiempo real son aquellos en los cuales no tiene importanca el usuario, sino los procesos. Por lo general, estén subutlizedos sus recursos con la finalidad de prestar atencién a los procesos en el momento que lo requieran. Se utiizan en entornos donde son procesados un gran niimero de sucesos 0 eventos. Muchos sistemas operatives de tiempo real son construidos para aplicaciones muy especificas, como control de tréfico aéreo, bolsas de valores, refinerias, etc. También en el ramo automovilistico y de la electrénica de consumo, las aplicaciones de tiempo real estén creciendo muy répidamente. Otros campos de aplicacién de los Sistemas Operatives de tiempo real son los siguientes: = Control de trenes. = Control automético de procesos quimicos. = Telecomunicaciones. © Obras consultadas: [1.18] [1.19] 27Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar = Sistemas de fabricacin integrada. = Produccién y distribucién de energia eléctrica = Control de edificios. = Sistemas multimedia, Algunos ejemplos de Sistemas Operatives de tiempo real son: VxWorks, Solaris, Lyns OS y Spectra, 1.3.5 Sistemas Multiprocesador, distribuidos y en red® Un sistema de cémputo multiprocesador es aquel con més de un CPU. Los dos grandes problemas que se tienen en este tipo de sistemas tienen que ver con: 1. El control de los procesadores. Dos o més procesadores similares estén conectados por medio de conexiones de alta velocidad y son administrados por un sistema operativo, donde cada procesador tiene el mismo acceso a los dispositivos de entrada/salida. Los procesadores son ‘tratados més 0 menos igual, permitiendo que los programas de aplicacién se ejecuten en cualquiera o tal vez, hasta en todos los procesadores del sistema, bajo la direccién del sistema operativo, EI multtiprocesamiento simple usualmente consiste en asignar a cada procesador una tarea fija (como administrar el sistema de archivos), reservando el CPU principal para tareas generales (fig. 1.15) iw Figura 1.15 Configuraciones de multiprocesamiento asimétrico(a) y simétrico(®). 2. La administracién de la memoria. Esta categoria puede ser subdividida en: a. Multiprocesadores de memoria compartida que tienen varios CPUs, todos con acceso a la misma memoria. La comunicacién entre los procesadores es facil de implementar, pero el punto critico es la sincronizacién del acceso a memoria b. Multiprocesadores de memoria distribuida con varios CPUs, donde cada CPU tiene su propia memoria asociada. Aqui, la sincronizacién del acceso a memoria no es un problema, pero la comunicacién entre los procesadores por lo general es lenta y complicada, © Obras consultadas: (1.20) (1.30) (1.31) 28Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar En los Sistemas Operativos Paralelos se pretende que cuando existan dos 0 mas procesos ue compitan por algtin recurso, se puedan realizar o ejecutar al mismo tiempo. En una maquina paralela, el sistema operativo paralelo se construye encima de los sistemas operativos (0 kernels) de cada procesador. Por ejemplo, en la IBM SP-2, el sistema operativo paralelo consiste de procesadores individuales ejecutando AIX y un componente unificador paralelo conocido como POE (Parallel Operating Environment), En UNIX existe también la posibilidad de ejecutar programas sin tener que atenderlos en forma interactiva, simulando paralelismo (es decir, atender de manera concurrente varios procesos de un mismo usuario). Asi, en lugar de esperar @ que el proceso termine de ejecutarse (como lo haria normalmente), regresa a atender al usuario inmediatamente después de haber creado el Proceso. Ejemplos de Sistemas Operativos Paralelos son: Alpha, PVM, la serie AIX (que es utilizado en los sistemas RS/6000 de IBM), Tornado, Hurricane y Helios. ‘También relacionado al multiprocesamiento se encuentran los siguientes tipos de sistemas: 2. Sistemas en red, que consisten de varias computadoras que estén conectadas entre si, usualmente con un sistema operative comtn y recursos compartidos. Los usuarios sin embargo, estén informados de las computadoras que conforman el sistema, Los sistemas operatives de red son aquellos sistemas que mantienen a dos o més computadoras unidas a través de algin medio de comunicacién (fisico 0 no), con el objetivo primordial de poder compartir los diferentes recursos y la informacién contenida en cada equipo. Los Sistemas Operatives de red mas usados son: Novell Netware, Personal Netware, LAN Manager, Windows NT Server, UNIX y, LANtastic. b. Sistemas distribuides, también consisten de varias computadoras pero differen del enfoque de redes en que estas computadoras son transparentes al usuario. Por lo general hay recursos redundantes y se comparte la carga de trabajo entre las diferentes computadoras, pero esto es transparente al usuario (fig. 1.16), Los sistemas operatives distribuidos permiten distribuir trabajos, tareas 0 procesos, entre un Conjunto de procesadores. Puede ser que este conjunto de procesadores esté en un equipo 0 en diferentes, en este caso es transparente para el usuario. Existen dos esquemas basicos: 1. Un sistema fuertemente acoplado es aquel que comparte le memoria y un reloj global, cuyos tiempos de acceso son similares para todos los procesadores, 2. En un sistema débilmente acoplado los procesadores no comparten ni memoria, ni reloj, ya que cade uno cuenta con su memoria local 29Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar Usuarios Figura 1.16 Exquema de un sistema operativo distribuido. Los sistemas distribuidos deben de ser muy confiables, ya que si un componente del sistema se descompone, otro componente debe de ser capaz de reemplazario. Entre los diferentes Sistemas Operativos distribuidos que existen tenemos los siguientes: Sprite, Solaris-MC, Mach, Chorus, Spring, Amoeba, Taos, etc. No hay que confundir un Sistema Operativo de Red con un Sistema Operative Distribuido. En un Sistema Operative de Red las computadoras estén interconectades por medios de comunicacién: software y hardware. En este tipo de sistema los usuarios saben donde estén ejecutando su trabajo y guardando su informacién. En cambio en los Sistemas Operatives Distribuidos existe un software que distribuye las tareas de los usuarios sobre una red de computadoras y para los usuerios es transparente donde realizan sus tareas y guardan su informacion. Existen dos esquemas basicos de éstos sistemas. Un sistema fuertemente acoplado es aquel que comparte la memoria y un reloj global, cuyos tiempos de acceso son similares para todos los procesadores. En un sistema débilmente acoplado los procesadores no comparten ni memoria ni reloj, ya que cada uno cuenta con su memoria local. 1.3.6 Computadoras Personales® En los inicios, los sistemas operativos estaban individualizados. Puesto que las computadoras eran una rareza, la cuestidn de la estandarizacién era ignorada, pues habia pocas computadoras para ello, y por Io tanto los SOs estaban atados a las capacidades y propésitos de cada sistema. La segunda forma en la que los programadores y usuarios retomaron las computadoras fue el advenimiento de las computadoras personales cerca de 1980. Finalmente las computadoras fueron suficientemente pequefias y baratas que un individuo podia tener una (fig. 1.17). Las primeras microcomputadoras fueron la Altair, la Commodore PET, la Tandy, y la Apple I (hay de hecho una Apple I, pero solo 200 fueron manufacturadas. Una de ellas cuelga en las oficinas de Apple con la leyenda "Nuestra Fundadora”), ® Obras consultadas: (1.25] [1.26] [1.27] [1.28] 30Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar La primera computadora de Tandy fue la TRS-80. La TRS, cuando se presenté, fue un gran éxito de venta gracias a su poderoso sistema operativo y el creciente numero de aplicaciones desarrolladas para él. En lo que fallé, fue en mantenerse al dia en los campos de mejoras de video y facilidad de uso de su SO. Las series Apple II (hasta que oficialmente fueron descontinuadas), fue usada por todos los sistemas escolares y muchos hogares estadounidenses. La Apple tenia varios sistemas operativos, como el Integer BASIC, el DOS 3.3, y el sofisticado ProDOS. © @® Figura 1.17 Las primeras PCs: (a) MITS Altair (1974), (b) Radio Shack TRS-80 (1977), (0) Apple I (1976), (d) Apple Lisa (1983). Sin embargo la mayor contribucién de Apple viene con la linea Macintosh. Steve Jobs estaba buscando una forma para mejorar la Apple II. En diciembre de 1979, fue invitado a participar en ln paseo por el centro de desarrollo de Xerox (PARC), el cual estaba tecnolégicamente avanzado para su tiempo y tenia dispositives de los que no se habia escuchado. Durante este paseo, le mostraron tres paradigmas revolucionarios: Ethernet, impresoras lser, y lo que més impresiono a Jobs, la interfaz gréfica de usuario (GUI). De inmediato Jobs vio esto como el futuro de los sistemas operativos (Io cual se plasmé en LISA). Cuando Commodore introdujo la PET, era bastante popular, pero no tanto como cuando introdujo su linea de 8-bits de color, con la VIC-20, la 64 y la 128. El contemporéneo sistema operative de Commodore estaba basado en su versién de BASIC. Todos los comandos a periféricos, los cuales eran “inteligentes” (tenian su propia memoria, procesador y manejadores), eran hechos por medio de BASIC; la computadora arrancaba en BASIC; y BASIC estaba construido en ROM. 31Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar La Commodore 64 fue la caja maravila para el mundo desde su llegada en 1982, con gréficos extraordinarios de 16 colores y sonido 3-voice, basada en la eficiente serie MOS 6500 (como rnota, una variante del 6510 de 16 bits, el 65816, es el que soporta al Super Nintendo). Puesto que el BASIC no tenia los comandos nativos para manipular muchas de las avanzadas caracteristicas de la 64, aparecieron una gran cantidad de accesorios: cargadores répidos para mejorar la velocidad de las unidades de disco 1541; extensiones de BASIC de todo tipo, y mejoras de hardware, como extensiones de RAM, cajas de alta velocidad RS232 e interfaces a impresoras no-Commodore. Otra clave fue el sistema operativo GEOS, hecho por Berkeley Softworks (ahora GeoWorks). ‘Aunque era lento y beligerante, desarrollé un fiel grupo de seguidores por a su poderosa GUI de 80 columnas (a la Mac) en la 64, y la gran cantidad de software existente para el (desde juegos hasta programas de negocio). La 64 podia incluso comportarse como una PC o estacién Unix programas como CS-DOS y los potentes sistemas operativos AG4/OS y Lunix, que convertian a la 64 en pequefias versiones de sus competidores mas grandes 0S9 fue uno de los pocos SO, sino el ‘inico, multitarea, multihilado y, con un poco de suerte, multiusuario en los sistemas de 8 bits. Corriendo en sistemas basados en versiones del 6809, como CoCos, para sistemas 68000 como el Atari STs, e incluso para la Apple Il La gran piedra angular de los sistemas operativos de & bits fue CP/M (el cual casi reemplaza al MS-DOS como el SO para la PC, de no haber sido por una compajiia de software de Redmond, ‘Washington que hizo un mejor trabajo de relaciones piiblicas). Desarrollado por Gary Kildall (de Digital Research) a mediados de los 1970s, CP/M fue el primer SO estandarizado jamas creado para microcomputadoras. CP/M tenia un conjunto estandar de comandos, (eventualmente) un OS estandarizado, e incluso utilerias del sistema. MS-DOS no fue el primero, ni el mejor de los sistemas operatives para microcomputadoras cuando fue licenciado por Microsoft para las PCs 1BM (el sistema operativo de Tim Patterson, QDOS como lo llamaba, no era enteramente suyo. El trabajo para Seattle Computer Products, asi que ellos poseian los derechos de QDOS. Microsoft decidié comprar los derechos de QDOS por US$50,000 y cambio su nombre a PCDOS 1.0 (cerca de agosto de 1981) Las primeras versiones presentadas eran similares al interprete de comandos de CP/M. MS-DOS fue escrito en lenguaje ensamblador de 16-bits (Intel) por lo que era dificil de portar a otras maquinas, a diferencia de CP/M, que en su mayor parte estaba escrito en un lenguaje de alto nivel. El DOS era un SO monousuario y monotarea, donde el usuario puede ejecutar un programa ala vez hasta su termino. 1.4 Comentarios La principal contribucién de todos estos desarrollos, fue enfrentar a un mercado creciente de Usuarios con necesidades de usabilidad. En retrospectiva, los cientificos que usaban las grandes computadoras estaban capacitados para operarlas, pero esto requeria de un alto grado de especializacién y es aqui donde las interfaces gréficas y los periféricos encontraron su lugar. En el siguiente capitulo se analizar el funcionamiento basico de un sistema operativo con el fin de integrar los conceptos expuestos hasta el momento. 32Disefi y situlacion de sistemas operativos ~ Eugenio Jacobo Hemsindez Valdelamnar 1.5 Obras consultadas [1.1] UC 2322 ~ sistemas Operatives ‘Apuntes O1 ler Semestre 1996 itp: /vawwccs.vigiiacedu/knabeic2332/ [1.2] ©5322: A Bia History of Computer Operating Systems Prof. R Bjork, Gordon Calaga hittpsjvawwres.gordone. edu/courses/cs322/lectureshist ony.td [1.3] Operating Systems Lecture notes Lecture 1: Overview and History Martin C. Rinard hp: /llamstalings.com/Extras/OS-Notes/notes. nt [14] A BRIEF HISTORY OF OPERATING SYSTEM'S "THROUGH TIME by Cameron Kaiser http: /wanw.armery.com/~specta/tech html [2.5] Brad A. Myers. "A Bri History of Human Computer Interaction Technclegy." [ACM interactions Vol 5, 0,2, March, 1998. pp. 44-54. [1.6] The computer museum histery center. Timaline of comauter history, hittp:/fvaww:computerhistory.org [1.71 Curso de sistemas operatives Enrique Sénchez Lara hitp:/laa.pue.udlap.mx/sist_operndex itm [18] Un paseo oor la historia Lidén Garcia , Luis Peralta & Samuel Fernindez hip: /spisa.act.j.es/~perata/es) [1.9] An Overview OF Computational Seience Copyrigat (C) 1982, 1992, 1983, 1994, 1995 by the Computational Science Education Project hitp://esep1.phy.oml.govfovjou.htmi [1.10] BITSYS: Operating Systems Lecture Notes hips/irenbarebendigelatrebe. edu au/subjets/otsys/ oslectfectisthtm [1.11] Curso de sistemas operatives Crysott hitp://ensoft.com/curses/endetale asp?pide=ssope [1.22] Inteduction to Operating Systems KatheynS, Mekiney. Unversity of Massachusetts Fall 1997 htto:sAwn-ami es umass.edu/es377) [1.33] DESDE QUE PULSAMOS EL BOTON DE NUESTRO PC HASTA, José Manuel Tela Lien exraido de microsoft publi. es.windows98 indows/art cule toss. dulens.n [1.14] How Operating Systems Werk Marshal Brain's HowStuftWores nto:/ Aw howstuffwerks com/eperating-system htm 1.15) Sistemas operatives I: Interupcienes del procesader tp:itveredu.mjsot/24.hem 1.26} C8277. Operating Systems (handouts) Hichae! Lynch nitp:/fwon.quete-commnel edu/lasses/ese277/handou ttm! [1.271 Intreduction to Operating Systems kath-yn S. Mekiney. Unversity of Massachusetts Fall 2997 nitp://w-ami.csumassedu/cs377) (1.28) Real Time Linux (R7-Linux) Allo Cuesta nitp://memberses-tined.de/Aiocy [1.39] Sstemas Operatives Curso 2000-2001 tp: fw. esi.uem.es/ngachet/s oper htm 11.20) Symmetric multiprocessing The Free Online Dictionary of Computing itp /ourks brighton. ac.uk/burksfoidoc/67/111.htm [1.21] Notas del Curso MATE 4096- Estructura de un ‘Sistema Operative to://euhww.uor ely edu/~jge/cursos/4096/netasing ‘09604 nen 11.22} Tomade eperating system lto:siw. eee torent edulperailtornade,htm 33Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar [1.23] Operating System Basies/Arctecture Kurt Hudson & Andy Ruth, Published: July 1999 host wawwewindowsiibrary.com/Content/175/00/toc im [1.24] x Window system Architecture Overview HowTo Daniel Manrique, 2001 hitos/linxseMhelp.com/HOWTO,peWindow-Overview HOWTO) [1.25] The machine that changed the world hitps//ees vt edu/~nstory/TNTCTW.hti 11.26) Smithsonian computer history hits//amarianstory.sedulsr/cemphist/coma botte mntm 1.27) Apple history. com nito:/Aw app histeryconytrames/? (1.28) O14 computers.com tosh old-comouters com [1.29] The cea history of the GUL nto:/ Aw webmacterdace com/artile/S13/62 [1.30) Clusters en México itp: /lusters.unammx(Histoia/ [1.31] How te ould a Beowuit tuterial nto Awiv.cacrcatern ed/becwulfutoia/tutorial:nt 34Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Capitulo 2. Funcionamiento basico de un sistema operativo La mayoria de las ideas fundamentales de la ciencia son esencialmente sencillas y por regla general pueden ser expresadas en un lenguaje comprensible para todos. Albert Einstein Una de las preguntas mas sencillas y comunes que podemos hacernos, es écémo funciona un sistema operativo?, la cual no tiene una respuesta trivial si tomamos en cuenta todos los elementos relacionados en su funcionamiento. En esta seccidn se trata de dar una respuesta que contemple todos los aspectos involucrados, tanto del hardware (donde se ejecuta el SO), como del software (el propio SO) en la etapa especiica en la que el SO toma control del hardware; el funcionariento de los componentes especficos del sistema se expone en los capitulos 3, 4 y 5. Este escenario es basico, pues es lo minimo indispensable que debe conocerse para construir Un sistema operative. Debe aclararse que mucho del material de este capitulo se basa en hardware de arquitectura secuencial y en especifico de PCs (Intel), asi como la interaccién del software a bajo nivel, lo cual es un proceso bastante genérico para casi todos los sistemas existentes. No se tratan cuestiones del funcionamiento de servicios més sofisticados como conectividad con redes o almacenamiento secundario. La idea es mostrar como el SO toma control del hardware y establece las funciones basicas para ejecutar e implementar servicios mas complejos. En las siguientes secciones se explica el funcionamiento de la unidad central de procesamiento (CPU) y la memoria, y los mecanismos de comunicacién entre los componentes de hardware (la descripcién esté hecha en base al comportamiento y componentes de una Ccomputadora personal, que es lo mas usado en estos dias), para después explicar a detalle el funcionamiento del sistema operativo, 2.1 El hardware y la ejecucion de programas® La Tuncién principal de una computadora es ejecutar programas, por lo que primero debe entenderse el funcionamiento del hardware de la computadora. Citando a Von Neumann, "para que un sistema de computo sea eficiente y de propésito general, debe tener una unidad central aritmética, una unidad central de control que orqueste todas las operaciones, una memoria, una Unidad de entrada y otra de salid © Obras consultadas: (2.1) (2.2) 35Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar : tit as — | case |_| vatatetnice |_| vas on pal) a Figura 2.1 Modelo de Von Neumann, Un sistema minimo de hardware esté compuesto por un procesador(CPU) que ejecuta las instrucciones provenientes de una memoria de cédigo (ROM), utilzando posiblemente una memoria de datos (RAM), e interactuando con dispositivos de entrada y salida (E/S), como teclado, monitor, discos, etc. Para comunicar a los distintos componentes, se utiizan un conjunto de cables por los que circulan los datos de un dispositivo a otro, 0 de un dispositive a la memoria y/o CPU, llamados buses (fig.2.2). No hay que olvidar dos componentes esenciales: el relo} (que es un mecanismo de sincronizacién) y la alimentacién (que es la que prove de energia a los componentes). (GLU, regaios Menara Ean contol) TT cr Ba ded Bud dienes Bede oat Figura 2.2 El procesador y demés dispositivos se conectan por medio de enlaces fisicos conocidos como buses. En las siguientes secciones se detalla el funcionamiento del CPU (0 microprocesador), la memoria y los mecanismos mediante los cuales se ejecutan los programas. 2.14 La unidad central de procesamiento® EI CPU (encarado fisicamente en un chip llamado microprocesador) ejecuta una coleccién de instrucciones de maquina que le dicen al procesador que hacer. Puede haber cosas muy sofisticadas que un microprocesador pueda realizar, pero en general 3 son sus actividades basicas: © Obras consultadas: (2.10] 36Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Usar su Unidad Aritmético/Légica (ALU). Un microprocesador puede realizar operaciones mateméticas como suma, resta, multiplicacién y divisién. Los microprocesadores moderos contienen procesadores completos de punto flotante que pueden realizar operaciones muy sofisticadas en grandes niimeros de punto flotante. Un microprocesador puede mover datos de una direccién de memoria a otra Un microprocesador puede hacer decisiones y saltar a un nuevo conjunto de instrucciones en base a dichas decisiones. Cory Clock Reset Cea) pa 3-state oo as ey iy er Counter c in) Read Address bus Data bus write Figura 2.3 Modelo de un microprocesador simple! El procesador de la Figura 2.3 tiene: un bus de direcciones (que puede ser de 8, 16 6 32 bits de ancho) que envia una direccidn de memoria un bus de datos (que puede ser de 8, 16 6 32 bits de ancho) que puede enviar datos 2 la memoria o recibir datos de la memoria tna linea de lectura RD (Read) y una de escritura WR (Write) para decirle a la memoria agregar u obtener el contenido de una direccién de memoria una linea de relo} que permite que un pulso de reloj mantenga la secuencia del procesador. tuna linea de reinicio (reset) que iniciaiza el contador de programa a cero y reinicia la ejecucién, ¥ sus componentes son: Los registros A, 8 y C son simplemente registros hechos con flip-flops. El registro de direccién es como los registros A, By C. " Imagen reproducida de [2.10] 37Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar EI contador de programa es un registro con la habilidad de incrementarse en uno, y poner su estado en cero cuando se le indica. EI ALU podria ser tan simple como un sumador de & bits, o podria ser capaz de sumar, restar, multiplicar y dividir valores de 8-bits. El registro de prueba (test register) es un registro especial que puede almacenar valores de comparaciones realizadas en la ALU. El registro de instruccién y el decodificador de instruccién son responsables de controlar a todos los demas componentes, Todo procesador posee un conjunto de instrucciones que puede realizar. Esta coleccién de instrucciones es implementada como un patrén de bits, y cada uno tiene un significado diferente al ser cargado en el registro de instruccién; una forma de representar estos patrones de forma un poco més legible, es mediante palabras o mneménicos conocidos como lenguaje ensamblador. Como ejemplo se presenta el conjunto de instrucciones en lenguaje ensamblador del procesador de la figura 2.3: LOADA mem - Carga el registro A de la direccién de memoria LOADB mem - Carga el registro B de la direccién de memoria CONB con - Carga un valor constante en el registro 8 SAVEB mem - Salva el registro B a la direccién de memoria SAVEC mem - Salva el registro C a la direccién de memoria ‘ADD - Sumar A y By almacenar el resultado en C SUB - Restar Ay B y almacenar el resultado en C MUL - Multiplicar A y B y almacenar el resultado en C DIV - Dividir A y 8 y almacenar el resultado en C COM - Comparar A y B y almacenar el resultado en test JUMP addr - Saltar a una direccién JEQ addr - Saltar si igual, a la direccién JINEQ addr - Saltar si no es igual, a la direceién JG addr - Saltar si es mayor, a la direccién IGE adcr - Saltar si es mayor o igual, a la direccién JL addr - Saltar si es menor, a la direccién JILE addr - Saltar si es menor 0 igual, a la direccién STOP - Detiene la ejecucién A continuacién se exponen detalles acerca de la memoria y como el CPU ejecuta los programas. 2.1.2 Lamemoria® El término memoria es técnicamente cualquier forma de almacenamiento electrénico (fig. 2.4). Anteriormente se hablé de los buses de datos y direcciones, asi como de las lineas RD y WR. Estos buses y lineas conectan tanto a la RAM como a la ROM. © Obras consultadas: (2.11) (2.15) (2.16] 38Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar La memoria de solo lectura (ROM-Read-Only Memory) es un chip programado con una configuracién permanente de bytes predefinidos. El bus de direcciones le dice a la ROM que byte obtener para colocarlo en el bus de datos. Cuando cambia el estado de la linea RD, la ROM coloca el byte seleccionado en el bus de datos. La memoria de acceso aleatorio (RAM - Random Access Memory) contiene bytes de informacién y el microprocesador puede leer o escribir esos bytes dependiendo de la linea que este sefialada (RD 0 WR). Un problema de los actuales chips de RAM es que “olvidan” todo una vver que no hay energia; esa es la razén de que las computadoras necesiten una ROM. EI ancho de los buses determina la capacidad de bytes de memoria que pueden ser direccionados, es decir, la cantidad de memoria del sistema. Por ejemplo en el microprocesador de la figura 2.3, si se tiene un bus de direcciones de 8 bits significa que el procesador puede acceder a 2° = 256 bytes de memoria, y puede leer o escribir 8 bits de la memoria a la vez. Figura 2.4 El CPU accede diferentes tipos de memoria. Al leer de un medio de almacenamiento permanente (p.ej. un disco duro) o algtin dispositive de entrada (el teclado), la mayor parte de los datos legan primero a la RAM. Ella almacena entonces piezas de datos que necesiten acceder continuamente en un eaché y mantiene ciertas instrucciones especiales en el los registros. Cabe menconar que es posible crear una computadora sencilla que no contenga RAM (muchos microcontroladores lo hacen incluyendo cierta de cantidad de RAM en el mismo chip), pero por lo general es imposible crear una computador que no tenga ROM. 2.1.3 Ejecucién de programas La ejecucién de un programa consiste en el preciso seguimiento de una secuencia de instrucciones de maquina, Puede asumirse que todas las instrucciones necesarias para que un programa se ejecute estén contenidas en la memoria de la computadora, en una secuencia ordenada. Cada instruccién esté formada por uno 0 mas bytes que contienen, codificada, la operacién a realizar, asi como también los datos involucrados en dicha operacién. Un programa 39Disedo y simulacién de sistemas operatives Eugenio Jacobo Hemindee Valdelamnar conocido como ensamblador puede traducir estas palabras a lenguaje maquina, para después colocar el resultado en la memoria para su ejecucién por medio de otro programa conocido como cargador. ” Wass M 10 12 1 LoADA 128 Lage 128 onda 128 savac 128 sume 4 Won Wit ae S the Wy ewe WP nents 1) Loop back irene y naunie a IT Baunie Fe Addr opcode/ 20 2 26 bn 28 128 Wy u u u “ws sKvER 128 save 12: LOAD 128 SAVER 128 Tabla 2. Comparacién de un programa en lenguaje de alto nivel, ensamblador y cddigo maquina La tabla 2 muestra un programa en lenguaje C, que es transformado por un compilador en lenguaje ensamblador y los cédigos de operacién correspondientes generados por el ensamblador, que son los que se cargan en memoria (la primera columna corresponde a la direccién de memoria y la segunda al cédigo de la instruccién). Para poder ejecutar un programa (fig. 2.5) es necesario traer cada una de estas instrucciones desde la memoria, hasta un registro de instrucciones (IR) que es interno y no accesible por el programador, en un proceso denominado fetch. Una vez en este IR, la Unidad Légico-Aritmética (ALU) podra ‘decodificar esta instruccién, y luego determinar cuales son los datos necesarios 40Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Estos pasos se llaman decodificacién de la instruccién, y decodificacién de direcciones, ya que gran parte de los datos estin en posiciones de memoria o registros que estén representados por direcciones. Luego la instruccién es ejecutada, para finalmente escrbirse los resultados en los registros de destino, que en general es el acumulador, y actualizarse las banderas (flags), en lo que se llama almacenamiento del resultado (Write-Back), Memoria oeccanes Dios ala mate a 1 2 3 ats oe mera i é 7 8 3 buecion 08 Leere scrbir ‘alos Figura 2.5 Esquema de la ejecucién de un programa, En resumen, los pasos requeridos son los siguientes: 1. Fetch: Traer instruccién desde memoria hasta el IR (Instruction Register). 2. Decodificar Instruccién: determinar la operacién requerida por la instruccién. 3. Decodificar Direcciones: De modo de poder acceder a los datos requerides para la ‘operacién. 4. _Bjecutar: Momento en el cual se realiza la operacién, y se entrega un resultado. 5. Write-back: Proceso de escribir este resultado en algun registro de destino, como lo es el acumulador. Lo anterior es lo més representativo de la mayoria de los casos, pero existen CPUs que incorporan muchas més etapas, debido a la complejidad de las instrucciones que procesan. La operacién se hace mas compleja cuando el sistema minimo integra cispositives adicionales. En la siguiente seccién se analiza la interaccién entre los componentes de hardware, donde vveremos que hay nuevas consideraciones para la ejecucién de instrucciones. 2.1.4 Interaccién entre los componentes de hardware® ‘Todos los dispositivs se conectan al BUS por medio de un controlador de entrada/salida. De esta manera dispositivos tales como el teclado, el ratén, 0 una tarjeta de red pueden producir entradas que deben ser procesadas por el CPU (fig. 2.6). © Obras consultadas: (2.3) 4Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar CPU race ee Diseotin ‘ses Bus deleictoma Figura 2.6 Los componentes de hardware pueden comunicarse con el CPU mediante controladores. EI CPU a su vez, se comunica con los dispositives por medio de instrucciones especiales 0 de direcciones de memoria concretas. Cada controlador tiene un buffer local, de donde el CPU recoge y envia datos. Pero, écémo se puede enterar el CPU que los datos estan ahi? Existen dos formas: + Elmétodo de polling + Eluso de sefiales de interrupcién La idea més simple, que no tiene porque ser la mejor, es que el CPU este comprobando una y otra vez si le han llegado datos. Cuando al fin los encuentre, los procesard. Este método es llamado polling, puesto que la CPU esté comprobando el dispositivo continuamente para ver si tiene informacién de algtin dato. Desgraciadamente, aunque el polling es muy simple, es también muy poco eficiente. El CPU esta desaprovechando su tiempo en espera de que le llegue la entrada, Una opcién mas elaborada es el uso de una sefial llamada snterrupeién, que es ls forma en que el controlador notifica al CPU de la finalizacion de una operacién o ta legada de nuevos datos. 1 CPU responde a la sefial de interrupcién dejando a un lado cualquier cosa que este haciendo para atender a la interrupcién, Una vez que ha terminado de atender (handled) la interrupcién, continua con lo que estaba haciendo antes de ser interrumpida, Por ejemplo, cuando se presiona una tecla de la computadora, el teclado envia una interrupcién al CPU, el cual responde a esta sefial interrumpiendo lo que estuviera haciendo, leyendo la tecla pulsada, procesdndola, y continuando con la tarea que estaba realizando antes de que la tecla se presionara, 42Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Un evento es normalmente una interrupcién de software (llamadas al sistema, divisién por cero (excepciones)) 0 hardware (p.ej. terminacién de E/S, alarmas del reloj, etc). Para provocar una interrupcién de software existe una instruccién de interrupcién especifica para cada maquina (INT (Intel); TRAP (Motorola); SYSCALL (MIPS)).. Cuando el SO recibe una interrupcién, el CPU guarda su estado (incluyendo la direccién de la instruccién interrumpida) y transfiere el control @ una posicién fijada en la memoria, que es la direccién de la rutina de la interrupcién. Después del procesamiento de la interrupcién, el SO recupera el estado guardado y la ejecucién continua donde fue interrumpida, En concreto, una interrupcién es un evento que altera la secuencia en que el procesador efecuta las instrucciones. Cuando ocurre una interrupcion: * El sistema operative toma el control (es decir, el hardware pasa el control al sistema operativo). + Elsistema operativo guarda el estado del proceso interrumpido. En muchos sistemas esta informacién se guarda en una estructura llamada logue de control de proceso interrumpide. + El sistema operativo analiza la interrupcién y transfiere el control a la rutina aproplada para atenderla; en muchos sistemas actuales el hardware se encarga de esto automdticamente. + Lanttina del manejador de interrupciones procesa la interrupcién. + Se restablece el estado del proceso interrumpido (0 del "siguiente proceso") + Se ejecuta el proceso interrumpido (o el "siguiente proceso’ Una interrupcién puede ser iniciada especificamente por un proceso en ejecucién, en cuyo caso se le suele denominar trampa (trap) y se dice que esta sincronizada con la operacién del proceso; 0 puede ser causada por algun evento que puede estar relacionado 0 no con el proceso en ejecucién, en cuyo caso se dice que la interrupcién es asincrona con la operacién del proceso, Esto implica un cambio en el enfoque de la ejecucién de instrucciones, pues ahora debe atenderse a las interrupciones. Por lo tanto, baséndonos en los pasos de ejecucién de la seccién anterior, tenemos la siguiente secuencia ampliada: Fetch: Traer instruccién desde memoria hasta el registro de instruccién (IR) = Ocurre al inicio de cada ciclo de maquina. ‘Ocasiona que una instruccién de maquina sea traida de memoria principal. ~ Pasos del ciclo: ‘Se asume que existe un reloj para sincronizar la ejecucién. ‘+ Tiempo 1: Mover el contenido del PC al MAR. + Tiempo 2: Mover el contenido de la direccién de memoria apuntado por el MAR al MOR. Incrementar el contenido del PC en uno. + Tiempo 3: Mover el contenido del MDR al IR. 2. Decodificar Instruccién: determinar la operacién requerida por la instruccién 3. Decodificar Direcciones: De modo de poder acceder a los datos requeridos para la operacién — Obtiene los operandos indirectos de la instruccién de maquina, = Objetivo es transformar un direccionamiento indirecto en uno directo. 43Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar 4. Interrupciones. —Pueden ocurrir al finalizar el ciclo de ejecucién, Se ejecuta si alguna sefial de interrupcién ha sido emitida. = Objetivo: + Guardar la siguiente direccién a ejecutarse. + Pasar el control a la rutina de interrupcién, ‘+ Retornar el control al proceso al terminar la interrupcién 5. Ejecutar: Momento en el cual se realiza la operacién, y se entrega un resultado. = El ntimero de micro operaciones a ejecutarse no es fijo como en los ciclos de captacién, indirecto e interrupcién, ~ La cantidad de micro operaciones depende de la instruccién de maquina, 6. Write-back: Proceso de escribir este resultado en algtin registro de destino, como lo es el acumulador. Cuando llega una sefial de interrupcién al CPU, este suspende su trabajo para eecutar una rutina de servicio de interrupcién (IRS 0 RSI). Antes de ejecutar dicha rutina, debe guardarse el estado del procesador, para que pueda continuar con sus actividades después de ejecutar la RSI. Debe recordarse que todo esto es un proceso puramente mecénico. La sefial de interrupcién del ispositivo, simplemente envia una sefial por un cable, El CPU estd construido para que cuando se reciba una sefial por ese cable, guarde la informacion que estd manejando en ese momento, y pueda volver a ese estado mas tarde, Esa informacién consiste en el contenido de los registros intemos importante como pueda ser el contador de instrucciones (PC). El CPU salta a una direccién de memoria predeterminada y ejecuta las instrucciones alli almacenadas. Estas instrucciones forman el manejador de interrupciones y definen el proceso necesario a realizar para responder a la interrupcién. (EI manejador de interrupciones, es parte del driver del dispositivo que ha activado la interrupcién). Al final del manejador de interrupciones, hay una instruccién que hace que la CPU realice un salto hasta donde estaba antes, restaurando previamente los datos guardados. Una pregunta légica de este proceso es: écémo se identifica al dispositive que lanzé la interrupcién? Para ello se tienen dos opciones: preguntar a todos los dispositivos (polling) 0 que el dispositive envie un numero (su identficador) por el bus (interrupciones vectorizadas) En el segundo caso, el CPU usa una tabla en memoria con las direcciones de las cistintas RSI que puede ejecutar (por lo tanto el numero enviado por el dispositivo es el indice en el vector de interrupciones). Las interrupciones permiten al CPU trabajar con eventos asincronos. Durante el didlo regular de leer-y-ejecutar, las cosas ocurren en un orden predeterminado, todo lo que pasa, esta sincronizado con todo lo demés. Las interrupciones hacen posible que el CPU pueda tratar eficentemente las cosas que pasan de manera asincrona, esto es, en momentos impredecibles, Un ejemplo det uso de las interrupciones, es lo que pasa cuando el CPU necesita acceder a datos almacenados en el disco duro. El CPU solo puede acceder directamente a los datos si estan 44Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar almacenados en la memoria principal. Los datos del disco, han de ser trasladados a memoria antes de que puedan ser accedidos. Desafortunadamente, en la escala de velocidades en las que opera el CPU, el disco es extremadamente lento. Cuando el CPU necesita datos almacenados en disco, envvia una sefial para indicarte al manejador del disco donde esta la informacién, y que esta preparada para recibirla. Esta sefial es enviada en forma sincronizada, bajo el control de un programa normal. Entonces, en vez de quedarse esperando una importante e impredecible Cantidad de tiempo @ que el disco lo haga, el CPU se dedica a alguna otra tarea. Cuando el manejador del disco tenga los datos disponibles, enviara una sefial de interrupcién al CPU y el manejador de interrupciones, leeré los datos solicitados en forma asincrona. + Tipos de interrupciones Existen tres tipos de interrupciones que pueden encontrarse en una computadora: a, Interrupciones internas de hardware. Las interrupciones internas son generadas por Gertos eventos que surgen durante la eecucién de un programa. Este tipo de interrupciones son manejadas en su totalidad por el hardware y no es posible mocificarias Un ejemplo claro de este tipo de interrupciones es la que actualiza el contador del reloj interno de la computadora, el hardware hace el llamado a esta interrupcién varias veces durante un segundo para mantener la hora actualizada. ‘Aunque no podemos manejar directamente esta interrupcién (no podemos controlar por software las actualizaciones del reloj), es posible utilizar sus efectos en la computadora para nuestro beneficio, por ejemplo para crear un "reloj virtual" actualizado continuamente gracias al contador del relo} interno. Unicamente deberos escribir un programa que lea el valor actual Gel contador y lo traduzca a un formato entendlible para el usuario. b. Interrupciones externas de hardware. Las interrupciones externas las generan los dispositivos periféricos, como pueden ser: teclado, impresoras, tarjetas de comunicaciones, etc. ‘También son generadas por los coprocesadores. No es posible desactivar a las interrupciones externas, Estas interrupciones no son enviadas directamente al CPU, sino que se mandan a un circutto integrado cuya funcién es exclusivamente manejar este tipo de interrupciones. c. Interrupciones de software. Las interrupciones de software pueden ser activadas directamente por el ensamblador invocendo al niimero de interrupcién deseada con la instruccién INT. El uso de las interrupciones nos ayuda en la creacién de programas, Utlizéndolas nuestros programas son mas cortos, es mas fécil entenderios y usualmente tienen lun mejor desempefio debido en gran parte a su menor tamafio. Este tipo de interrupciones podemos separarlas en dos categorias: las interrupciones del sistema operativo y las interrupciones del firmware (p. Migracién de sistemas operatives. Dado un sistema con una arquitectura modular, podria seleccionarse un subconjunto de méddulos tales que puedan formar una nueva distribucién del meta conjunto de médulos (algo similar a lo que ocurre con las distintas distribuciones de Linux actualmente), portarla a una arquitectura especifica, soportar un tango mas amplio de dispositivos y servicios, > Desarrollo de SOs basado en componentes, de forma que puedan probarse nuevos kernels, servidores, manejadores, cargadores, etc. en diferentes condiciones y configuraciones (podria ser el inicio para una herramienta RAD) Un ejemplo de esto es la propuesta del OSKit con un enfoque basado en componentes, donde los disefiadores de SOs se beneficiarian de las técnicas de ingenieria de software como la orientacién a objetos y excepciones, tal como los desarrolladores de aplicaciones lo hicieron en la década de los noventas. Algunos de los enfoques de los simuladores existentes se orientan a: + Modelar componentes aislados de los SOs © Modelos estaticos de SOs + Simulacién de hardware para ejecucién de nuevos modelos de SOs Imagen reproducida de [3.22] 62Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Este ultimo enfoque es tal vez el més flexible y més complejo a la vez. En la siguiente seccién se presentan los fundamentos de la simulacién de hardware. 3.2 Emulacién y Simulacién de hardware? Si en el proceso de disefio de un modelo de simulacién de sistemas operativos, se opta por modelar ef hardware en el que se ha de ejecutar, es necesatio revisar los enfoques que pueden utiizarse para hacerlo. Para ello, podemos citar dos técnicas principales: > La Emulacién, que es un intento de imitar el disefio interno de un dispositive. Por ejemplo, Un programa que imite el hardware de las “maquinitas" (arcade) de Pacman, y ejecute una ROM de Pacman real en él, es un emulador. La Simulacién, que es un intento de imitar las funciones de un dispositive. Un juego de Pacman escrito para una PC que usa gréficos similares a la maquina del juego original, es un lador. v ‘Ambos enfoques son presentados en las siguientes secciones. 3.2.1 Emulacién de hardware Cuando una computadora trata de emular a otto procesador (tal como la PowerPC trata de emular un 80486), algunas traducciones de cédigo deben suceder antes de que cualquier programa pueda ser ejecutado en el emulador. Referirse a la traduccién de cédigo, implica que el procesador huésped (p.ej. PowerPC) y el procesador invitado (p.ej. 80486) son diferentes, por lo que tienden a efectuar sus operaciones de maneras distintas. Estas "maneras" de ejecutar operaciones son conocidas como instrucciones, y puesto que ambos chips tienen diferentes conjuntos de instrucciones, el software de emulacién debe encontrar una forma de resolver las diferencias entre ambos. Existen 3 esquemas bésicos que pueden ser usados para un emulador (y pueden ser combinados para un mejor resultado): 1. Interpretacién. Un emulador lee cédigo emulado de la memoria byte a byte, lo decodifica, y realiza los comandos apropiados en registros emulados, memoria y entrada/salida. El algoritmo general pata tal emulador es el siguiente pseudocédigo: ras (CPUEn! Fetch opcode Interpretar opCede © Obras consultadas: (3.3) [3.4] [3.5] 63Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Las virtudes de este modelo induyen la facilidad de depuracién, portabilidad, y facilidad de sincronizacién (simplemente pueden contarse los ciclos de reloj pasados y ligar el resto de la emulacién al ciclo actual). La tinica gran debilidad obvia es el bajo rendimiento. La interpretacién toma demasiado tiempo del CPU y puede requerirse una computadora muy répida para ejecutar el cédigo a una velocidad razonable. 8 ° Figura. 3.2 Emulacién interpretativa En a figura se muestra el proceso de emulacién (interpretativa): {A Las instrucciones del procesador Intel son enviadas al software de emulacién. B. El software de emiulacién tracuce las instrucciones Intel a instrucciones Motorola . Estas instrucciones son enviadas al procesador Motorola para su ejecucién, D. después de que las instrucciones son ejecutadas, son olvidadas. En esta técnica, se toma un programa escrito en el cédigo a emular y se intenta traducir al cédigo ensamblador de la computadora huésped. El resultado seré Un ejecutable comin que puede ejecutarse sin herramientas especiales. Mientras que todo esto suena muy bien, no es siempre posible. Por ejemplo, no es posible recompilar estéticamente Cédigo auto-modificable, pues no hay forma de predecir en que se convertiré hasta ejecutarto Para evitar tales situaciones, se puede tratar de combinar el recompilador estatico con un intérprete o un recompilador dinémico. 3. Recompilacin Dinamica. La Recompilacién Dindmica es esencialmente lo mismo que la estatica, pero ocurre durante la ejecucién del programa, En lugar de tratar de recompilar todo el Cédigo en un solo intento, se hace al vuelo cuando se encuentra una instruccién CALL o JUMP. Para incrementar la velocidad, esta técnica puede ser combinada con la recompilacion estatica. as NE net Fri Power Pc Figura 3.3 Emulacién de compilacién dindmica En la figura se muestra el proceso de emulacién dinamica: ‘A. Las instrucciones del procesador Intel son enviadas al software de emulacién. 64Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar B. El software de emulacién traduce las instrucciones Intel a instrucciones Motorola, y envia estas instrucciones a un buffer especial donde pueden ser almacenadas y reusadas. G. Las Instrucciones del buffer pueden ser enviadas al procesador Motorola para su ejecucién. D. Después de que las instrucciones han sido ejecutadas, pueden ser vueltas a llamar del RAM buffer, por lo que se elimina la necesidad de recompilarlas. Esta emulacién es mucho mas répida, + 4Cémo se instrumenta un emulador? Para escribir un emulador, debe contarse con un buen conocimiento de programacién de computadoras (ensamblador y algin lenguaje de alto nivel) y electrénica digital. Los pasos principales son: Seleccionar el lenguaje de programacién a usar. Encontrar toda la informacién disponible sobre el hardware a emular. Escribir a emulacién del CPU u obtener algtin cédigo existente para le emiulacién del CPU. Escribir un prototipo del cédigo para emular el resto del hardware, al menos parcialmente, En este punto, es util escribir un depurador integrado que permita interrumpir Ia emulacién y ver lo que el programa esta haciendo, Puede también necesitarse un desensamblador del lenguaje ensamblador del sistema emulado (hay que escribir un propio si no existe alguno). 6. Tratar de ejecutar programas en el emulador. 7. Usar un desensamblador y un depurador para ver como los programas usan el hardware y ajustar el cédigo del emulador 3.2.2 Simulacién de hardware® El problema de simular hardware se origina de tratar de reproducir el paralelismo inherente de los circuitos electrénicos, usando lenguajes de programacién que son de naturaleza y disefio secuencial. El fundamento central de cualquier simulador, es el concepto de tiempo, y como los elementos que conforman un componente se comportan a través de él El enfoque tradicional para simular dispositivos paralelos es tratar a todos los componentes como si estuvieran sincronizados con respecto a la llamada cola global de eventos (global event queue). Esta estructura consiste basicamente de una lista ligada de nodos de tiempo, donde cada nodo tiene un apuntador a una lista de componentes, o eventos, que tienen que ser procesados en el tiempo indicado. Todos los eventos ligados al mismo nodo de tiempo estén esencialmente en paralelo entre si Cuando un componente produce una salida, todos los componentes que tienen una entrada que depende de la salida son colocados en la cola global de eventos en el nodo que representa el momento en que la sefial de salida fue producida. Puesto que los nodos de tiempo son © Obras consultadas: (3.6) 65Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar secuenciales, los componentes conectados a cada uno de los nodos son simulados y mas eventos son planificados para instantes posteriores, reflejando la salida de estos componentes. Esto continua hasta el fin de la cola de tiempos es alcanzado o el tiempo asignado para la simuladén se acaba Un segundo enfoque, las colas de eventos distribuides, consiste en encapsular una o mas colas dentro de lo mismos componentes, por lo que se elimina todos los problemas inherentes de mantener una estructura global. Las colas son distribuidas en el componente y pueden existir en casi cualquier nivel de descripcién. Cada cola mantiene la historia de sefiales que han sido enviadas al componente durante el curso de la simulacién y mantiene una lista de todos los Componentes que estén a la espera de la sefial. Por lo tanto, la cola distribuida sirve como un conector entre 2 componentes y también sirve como el medio en que las sefiales pueden propagarse en paralelo usando un lenguaje secuencial de programacién. Con respecto al hardware, las colas de eventos distribuidos representan cables; las sefiales, viajan a través de cables, y los cables conectan a los componentes entre si. Puesto que las colas Y los cables realizan la misma funcién y estén estrechamente relacionados, el concepto de colas distribuidas es mucho més atractivo e intutivo que una cola global de eventos. Todos los componentes son simulados de la misma manera, En términos de pseudocédigo, el algoritmo podria resumirse como: funcién simular (componente) entras (las entradas al componente estén Listas) hacer incrementar tiempo local del componente si (el compenente no tiene subcomponentes) ente lamar funcién de proceso virtua para cada (puerte de entrada del componente) hal para cada (elemento en el puerto de salida) hi ar funcién simular de salida EI simulador no es un teemplazo para un emulador. Un simulador es _una_herramienta totalmente diferente. Mientras que un emulador permite depurar el software ejecuténdolo en un hardware especifico, un simulador permite depurar el software asi como entender el microprocesador y el lenguaje de programacién 3.3 Maquinas virtuales® El concepto de méquinas virtuales es usado a menudo en computacién para solucionar problemas importantes, pero por lo general estos son transparentes al usuario (son usadas en programas y sistemas operativos). Algunos de estos problemas incluyen ‘= compartir el mismo hardware entre varios programas dividiendo el hardware disponible, © Obras consultadas: (3.7) [3.8] 66Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar ‘+ permitir al software ser “portable” entre varios sistemas operatives, ‘= ejecutar viejo software en una computadora mas nueva. EI término “Virtual” ha evolucionado para describir casi cualquier cosa que sea una simulacién de un objeto real, con términos como memoria virtual, discos virtales, y realidad virtual. En el caso de las maquinas virtuales se desea que estas se vean y comporten exactamente como una maquina real. Esto significa que la maquina virtual no es realmente de hecho una maquina, pero se comporta exactamente como una verdadera. Todas las méquinas tienen una cosa en comtin, ya sea un microondas, un refrigerador, una reproductora de video 0 una computadora; todas ellas estén disefiadas para llevar a cabo clertos tipos de conjuntos de instrucciones. Los conjuntos de instrucciones, pueden ser concebidos para cualquier maquina como piezas (como las de un rompecabezas 0 Lego) que al unirlas forman un objeto completo. Con las méquinas, estas piezas son instructiones, las cuales son usadas para decirle a la maquina que hacer o que tareas realizar. En el caso de las maquinas virtuales, lo virtual se refiere a los conjuntos de instrucciones. Hay muchos tipos de méquinas virtuales, pero lo comin entre ellas es la idea de simular un conjunto de instrucciones. Cada maquina virtual usa un conjunto virtual de instrucciones al que el usuario tiene acceso, y despues la méquina virtual "mapea” estas instrucciones virtuales a instrucciones reales de la computadora. Hay cuatro corrientes principales en esta érea: a, La primera es un mapeo (casi) uno a uno (representado por el modelo de maquina virtual de 18M). b. La segunda consiste de un mapeo de cada instruccién en la maquina con una instruc virtual (representada por la maquina virtual de Java). . Los modelos de méquinas virtuales de Unix y OSI representan los ultimos dos modelos, los cuales mapean algunas de las instrucciones directamente, y otras son llamadas directas a las funciones del sistema operativo, Los modelos han sido utilizados para resolver problemas como: particionar una maquina (modelo 18M), crear una semi-plataforma independiente para lenguajes de programacién (modelo Java), y crear sistemas operativos (modelo Unix y OSI). El poder y éxito del concepto de la maquina virtual viene de brindar a los usuarios la habilidad de acceder y utilizar funciones y dispositives que son simples combinaciones de conjuntos de instrucciones. La habilidad de prover una solucién virtual a las limitaciones reales de los sistemas de cémputo modernos es una herramienta muy poderosa que continua extendiendo las habilidades de los sistemas modernos. 3.3.1 El sistema P® Un caso interesante relacionado a las méquinas virtuales es el sistema P, el cual estd relacionado a RCOS, una de las plataformas de simulacién de sistemas operativos que se analiza en las siguientes secciones. © Obras consultadas: (3.9) [3.10] 67Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar EI sistema P es un sistema operative portable que fue popular en los primeros dias de las computadoras personales, a fines de los 1970s y principios de los 1980s. El sistema-P, como Java actualmente, estaba basado en una maquina virtual con un conjunto esténdar de instrucciones de "cédigo-p" (p-code es un lenguaje de méquina de bajo nivel para tuna maquina de pila hipotética llamada maquina-P, que es una imitacién del conjunto de instrucciones de la Burroughs Large System) que eran emuladas en hardware diferente, incluyendo e! 6502, el 8080, el 2-80, y el PDP-11. En esta forma, un compilador de Pascal que emitia ejecutables de cédigo-p, podia producir programas que podian ejecutarse en los sistemias P en las Apple Il, Xerox 820, 0 una DEC POP-11. El lenguaje més popular para el sistema P era el UCSD Pascal. De hecho, el sistema operativo del sistema P estaba escrito en UCSD Pascal, haciendo al SO relativamente facil de portar entre plataformas. Al escribir un interprete de cédigo P en el lenguaje ensamblador nativo de la plataforma y haciendo unos cuanto ajustes minimos a las funciones del sistema operative (sistemas de archivos e interaccién con el usuario), era posible llevar ejecutables de un sistema y ejecutarlos en una nueva plataforma, 3.4 Plataformas de simulacién de Sistemas Operativos Al principio de este capitulo se mencioné que existen varios proyectos y enfoques en la simulacién de sistemas operativos. Para comprender mas a fondo como funcionan dichos modelos, se han incluido como casos de estudio: a. Java Operating System Simulator b. Nachos c RCOS A continuacién se exponen brevemente las caracteristicas de cada uno de estos simuladores. 3.4.1 Java Operating System Simulation” Para tratar de responder a la pregunta "éy como se implementa un servicio de planificacién?" se presenta el Java Operating System Simulation (una aplicacién hecha por Tony Teal que simula colas de planificacién para procesos y dispositivos) para analizar cémo funciona la planificacién de procesos. Los archivos que lo conforman son: > OSProcess.java Representacién de una tarea del sistema. OSQueue,java Representacién de las colas ready y de E/S. OSDevice.java Representacién de un CPU o un dispositivo de E/S. OsSystem.java Contiene 2 objetos Queue y 2 objetos Device. v vv ” Para més detalles sobre la administracién de procesos y conceptos relacionados consult el capitulo 4 68Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Si se desean ver algunos detalles de bajo nivel como el intercambio de procesos, puede verse el apéndice "Caso de estudio: Implementacién de un microkernel”. Hasta el momento se ha establecido que las principales entidades que deben implementarse son: + Procesos + Colas de procesos Adicionalmente, puede incluirse a los dispositives, pues como se mencioné hay procesos que pueden estar relacionados con el uso de los periféricos de la computadora, ‘Sea entonces un sistema que puede contener uno 6 més dispositives (tomando en cuenta al CPU como dispositive), los cuales tienen asociada una cola de procesos. Cada cola puede implementar un algoritmo de planificacién para administrar los procesos creados en el sistema. Aunque una decisién posible es implementar estas colas con estructuras de datos FIFO, ef asunto es que dichas estructuras consumen memoria y no son la opcién de implementacién si lo que se desea es rendimiento y velocidad (ademas de que lo que deseamos ver es como lo hacen a bajo nivel) age Cres PA Prociaenney Figura 3.4 Clases y métodos del JOSS. Lo primero que hay que hacer es contar con un bloque de control de proceso, donde se puedan integrar los conceptos de identificador de proceso (ID), prioridad, tiempos de respuesta y un ‘apuntador al proceso siguiente. public class osProcens extends object { int ids 69Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar at iat nt epu_time_total; nt jo Eime_required; nt response_tines Lat time_ins Public int TextPos; /* next process ar Hecho esto podemos hablar de la estructura que contendré y planifcaré a los procesos. Cada cola debe tener un maximo de procesos que puede atender (esto de forma dindmica tiene que ver con la memoria disponible del sistema) asi como implementar un tipo de algoritmo de planificacién (esto lo implementa la clase OSQueve). La principal operaciones de una cola de procesos es insertar un proceso en la estructura (insert), publ: 5 osquene ex object nt queveType; /* 1 = FIFO, 2 = LIFO, 3 = Sc, nt maxBlements, curleneats, alead; public Osquese(int q) int max} queueType = a2 Esta implementacién en particular usa una estructura osProcess(] ProcessArray que se encarga de almacenar todos los procesos del sistema. Debe resaltarse que esta estructura no pertenece a OSQueve, sino que aplica para cualquier cola de procesos existente en el sistema. Lo que sucede, es que al llamar al método insert de OSQueue, de actualizan los indices a los procesos siguientes de los PCBs, Esta implementacién permite que cualquier cola de procesos pueda usar diferentes algoritmos de planificacién. sod on the quese type's #47 ena met be Ph next in line to leave, #87 We are ing Insert"); sments == maxslemeats) J+ Round Robin */ 70Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar ead == -1) | jena] system (Mie are in FIFO while pte =" ccwasArraylptr) nex: Pon? ' ‘moout,printin("We are leaving PIPO; current clenente: "* ‘Tomemos como ejemplo la implementacién para los algoritmos FIFO y Round robin (que en este caso es casi lo mismo). En realidad se esta implementando una estructura FIFO, pero lo interesante es que la insercién solo esté operando sobre los indices del arreglo principal de procesos. Si el dispositivo en el que el proceso se ejecuta es el CPU se incrementan los valores de tiempo que el proceso ha pasado en el dispositivo; lo mismo pasa para la E/S. F (devName.equais ("CPU") System.out.printin("gtype inside: “+devName) ¢ ossysten, ProcessArray [curr_process] .cpu_tins if (devNane. To dev ‘r_process].io_time_totalt+: dleviane} + cat.printini"gtype insid ossysten. Prosassarray| 3.4.2 Nachos® Nachos es un software instruccional que permite a los estudiantes analizar y modificar un sistema operativo real operacional. Fue desarrollado en la Universidad de Berkeley y es usado por varias escuelas para la ensefianza de cursos de sistemas operativos. Como en cualquier sistema operativo, hay un planificador (Scheduler) que mantiene el control de los procesos en el sistema y los alterna periédicamente, y mantiene una lista de procesos (readyList) para este propésito. Todos los procesos en Nachos se ejecutan como hillos. Esto significa que todos los programas que se ejecutan en Nachos son implementados como hilos. © Obras consultadas: (3.11) [3.12] (3.13) 7Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Stats Machine Interrupt Torreks eper oO isk! tegen Timer “Smomete'eger ‘eats ager rubaifease reger rumbles: eget ‘rbot ge ‘numPacketsRecva! Imager Nachos me TeaiToseee cert Scheduler SynchDisk —_ | PostOitice Figura 3.5 Forma en que los diferentes componentes de Nachos estén ligados durante la ejecucién* EI lapso de tiempo para la ejecucién de cada proceso es determinado por el componente ‘Temer, que causa una interrupcién cuando el lapso de tiempo para un proceso en ejecucién expira. El componente Interrupt maneja todas las interrupciones generadas por el componente Timer. La causa de las interrupciones pueden ser la E/S de algin dispositivo (p.ej. la escritura a un archivo por parte de un proceso, una sefial del planificador para cambiar a otro proceso, ett.) Todos los sistemas operativos necesitan al hardware para ejecutar sus procesos. El componente Machine prove dicha funcionalidad, al simular la arquitectura MIPS. €l componente FileSystem administra todas las operaciones de archivos. SynchDisk provee acceso sincronizado al disco. Para conectar una maquina con otras, se tiene el componente PostOffice que administra la recepcién y envio de mensajes a través de una red. Stats es un componente que mantiene Ciertas estadisticas sobre la ejecucion y eficiencia del sistema. Por ejemplo, puede mantener el rastro de cuantos caracteres han sido escritos en la pantalla, cuantos errores de paginacién han cocurtido, cuantos paquetes han sido recibidos por medio de la red, etc. + Lamaquina Nachos Nachos simula una méquina parecida a la arquitectura MIPS. La maquina tiene registros, memoria y CPU. Ademés, un reloj simulado manejado por eventos provee un mecanismo para planificar las interrupciones y ejecutarlas posteriormente. La simulacién de la maquina MIPS Puede ejecutar cualquier programa. Solo hay que cargar las instrucciones en la memoria de la “Imagen reproducida de [3.11] 2Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar maquina, inicializar los registros (induyendo el contador de programa PCReg) y entonces decirle a la maquina que empiece a ejecutar las instrucciones. La maquina obtiene entonces la instruccién a la que apunta el PCReg, la decodifica y ejecuta. El proceso es repetido indefinidamente, hasta que una operacién ilegal es realizada o una interrupcién de hardware es generada. Cuando ocurre una trampa o interrupcién, la ejecucién de las instrucciones MIPS es suspendida, y una rutina de servicio de interrupcién es invocada para atender la peticién, Conceptualmente, Nachos tiene 2 modos de ejecucién: + Nachos ejecuta procesos a nivel de usuario cargéndolos en la memoria del simulador, inicializando los registros del simulador y luego ejecutando el simulador. Los programas de usuario solo pueden accesar la memoria asodada con la maquina simulada, ‘+ El segundo modo corresponde al kernel de Nachos. El Kernel se ejecuta cuando Nachos se inicia, 0 cuando un programa de usuario efecuta una instruccién que causa una trampa de hardware (p.ej. una instruccién ilegal, fallé de paginacién, llamada al sistema, etc.). En modo de kernel, Nachos se ejecuta igual que un proceso normal de Unix. &5 decit, las declaraciones correspondientes al cédigo fuente de Nachos son ejecutadas, y la memoria accesada corresponde a la memoria asignada a las variables de Nachos. 3.4.3 RCOS® RCOS esta implementado en Java (aunque la distribucién original esté en C++), y pertenece a la categoria de sistemas operatives basados en kernels. RCOS.java esta dividido en las siguientes secciones: 1. Hardware + CPU. Hasta el momento esté basado en el cédigo de la maquina P. La intencién es reutilizar el compilador RCOS PLL2 y el intérprete de C++ existentes. + Disco. Se usa una estructura pequefia para producir una representacién gréfica de la asignacién/desasignacién de los bloques del disco por medio del sistema de archivos. * Terminal y Memoria (RAM). La Terminal provee la interfaz fisica con el usuario, incluyendo el tedlado y monitor. La Memoria consiste de 2 secciones. La primera es el cache del CPU, la ‘cual es ajustada dindmicamente para almacenar programas en ella. Esto incrementa la velocidad y reduce la complejidad principalmente. La memoria RAM secundaria contiene todos los programas cargados y los almacena en dos secciones: cédigo de proceso y pila (stack 2. Sistema operative = Kernel, RCOS usa un micro-kernel basado en una estructura de paso de mensajes. El kernel es responsable de varias funciones especificas de la plataforma incluyendo: a, manejo de interrupciones b. salvado/restauracién del contexto (saving/retrieving context) © Obras consultadas: (3.16} [3.17] (3.18] [3.19] [3.20] BDisedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar . generacién de mensajes al componente apropiado del SO como resultado de una llamada al sistema + Paso de mensajes (Message passing). Las funciones esténdar del sistema operativo estan divididas en diversos componentes. Toda la comunicacién entre ellos debe ser en forma de mensajes. Todos los mensajes pasan por el componente Post Office que es responsable de entregar los mensajes a los destinos correctos. La intencién es que componentes diferentes puedan ser localizados en computadoras diferentes. = Funciones de! SO. Las responsabilidades restantes de SO estén divididas en los siguientes componentes: 2. Planificador de disco. Responsable de administrar las peticiones de planificacién al disco, traducir los nimeros de bloque légico a sectores especifices del disco, cilindro y superficie. Hay un planificador de disco para cada disco. b, Sistema de archivos. Responsable de implementar un sistema de archivos particular (MS-DOS, CP/M, UNIX, NTFS, etc.). Maneja mensajes esténdar como abrir archivo, cerrar, leer, escribir, abrir directorio, obtener atributos del archivo, etc. Es posible para una instancia del ‘RCOStener varios objetos FileSystem, dando la habilidad para soportar mas de un sistema de archivos a la vez c Planificador de procesos. Responsable de administrar le creaciin de procesos, terminacién y planificacién, Maneja mensajes como dividir un proceso (fork), ejecutar proceso, matar un proceso, planificar un nuevo proceso, bloquear proceso, etc. Mantiene todas las colas de discos e incluye métodos como runningToReady, runningToBlocked, sgetNextRunningProcess, d, Administrador de memoria. Responsable de administrar la memoria, asignar y desasignar memoria para los procesos, lectura y escritura de memoria para otros ‘componentes. , Terminales. Proveen el mecanismo para escribir/leer a/de una terminal. 3, Animacién El sistema de Animacién esta oculto del resto del sistema por la clase Post Office Animator. Sus responsabilidades incluyen + dibujar la pantalla de perspectiva principal + manejar eventos de entrada e inicializar nuevos hilos para manipular la animacién de varios componentes del SO. = decidir que mensajes son interesantes para el sistema de animacién y distribuirlos en los hilos apropiados (si existen). 74Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar ao eee Operating pet Semel d Figura 3.6 Arquitectura del RCOS” 3.5 Simulacién de un Sistema Operativo minimo Aunque seria en extremo interesante poder simular cada una de las configuraciones histéricas de los diversos sistemas operativos (una idea extremista pero interesante si se quiere hacer una exploracién desde os inicios), esto seria en extremo un esfuerzo de mucho tiempo y escapa al objetivo de este trabajo. Para capitalizar las ideas expuestas anterformente, con respecto al funcionamiento de un sistema operativo (capitulo 2) y la simulacién de este tipo de sistemas, en esta seccién he documentado una primera experiencia en este sentido. En cuanto todos los concepts y sus interacciones cobraron sentido, se decidié hacer el intento de codificar un simulador que hiciera las cosas mas sencillas que un SO se supone que realiza. La primera pregunta que surgié fue: émodelar solo el SO, 0 se requiere modelar también el hardware donde se ejecuta? Este primer problema no es tan sencillo como podria suponerse. Modelar una computadora es un efercicio bastante complejo; y por lo visto hasta el momento un SO también es un sistema bastante complejo, como para aumentar la complejidad de la implementacién. Sin embargo, hay algunos hechos que no pueden dejarse de lado: Imagen reproducida de [3.17] 78Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar ~ el sistema operativo se crea para administrar los recursos de una computadora; = ef SO en la mayoria de los casos es muy dependiente del hardware, pues aunque se creen abstracciones de alto nivel para modelar sus servicios, los niveles de base siguen encargados de el acceso al hardware y su control; = el SO por mas portable que sea, necesita realizar funciones basicas para su inicializacién y configuracién, las cuales son dependientes de los recursos y arquitectura de la computadora Esto deja claro que es necesario modelar el hardware para tener una simulacién completa, Basta con ver los casos de estudio expuestos (NachOS y RCOS) para ver que es necesario (consult los detalles de la implementacién en el Apéndice. Simulacién de un sistema minimo de hardware y su sistema operativo) 3.5.1 El hardware: URM Asi, se decidié retomar un modelo de computadora llamado URM (Unlimited Register Machine) implementado en el curso "Computabilidad y Funcones recursivas’ de la licenciatura en Ingenieria en Computacién (FAR). Puesto que este modelo es un procesador abstracto, y tiene muy poces instrucciones, es un ejemplo de dimensiones controlables (haber elegido un microprocesador como un Pentium o un PowerPC, seria tema de otro trabajo). La URM tiene un numero infinito de registros (R1,R2,R3...) cada uno de los cuales contiene en todo momento un numero natural. El contenido de los registros puede ser alterado por la URM en respuesta a clertas instrucciones que puede reconocer. Estas instrucciones corresponden a operaciones simples usadas para realizar célculos con numeros. Una lista finita de instrucciones constituye un programa. Las instrucciones son las siguientes: = 2n). Instruccién cero. Cambia el contenido del registro Rn a cero, dejando sin alteracién a los demés registros = S(q). Instruccién sucesora. Incrementa el valor del ntimero contenido en Rn en 1, dejando a los otros registros sin alteracién. ~ T(m,n). Instruccién de transferencia. Reemplaza el contenido del registro Rn por el valor contenido en Rm. = 1(m,n,q). Instruccién de salto. El contenido de los registros Rm y Rn son comparados; si rm=m la URM procede a la instruccién q-ésima del programa en ejecucién; si rm<>m la URM procede a la siguiente instruccién. En la implementacién original del simulador de la maquina URM, la idea era darle a la maquina Un programa escrito con las instrucciones del modelo, y que este las ejecutara. Retomar este simulador con el fin de simular un sistema operativo minimo (SOM) requiere de nuevas consideraciones y varios cambios. La consideracién principal debe ser el separar los componentes de hardware y software del modelo. Ademés en la implementacién origina: + la carga de los programas, la hacia el simulador, y no habia explicitamente en el modelo un cargador de programas. + la URM no constaba con hardware adicional (periféricos); solo la unidad de procesamiento, sus registros y la memoria de programa. 16Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Si consideramos que la URM es un procesador, es posible usarla bajo el modelo de Von Neumann, y con ello modelar el hardware de una computadora que lo use. Por lo tanto, ef sistema minimo requeriria de: 1. Un procesador y sus registros. 2. Memoria principal Las instrucciones del modelo y su implementacién conformarian el conjunto de instrucciones del procesador (y nos podemos dar el lujo de implementar una pequefia ALU para las cuestiones de operaciones aritméticas). Ademés puede incluirse parte del funcionamiento del modelo Von Neuman, agregando un ciclo de fetch y uno de ejecucién al ciclo de instruccién de la maquina. Estas inclusiones requieren de agregar al modelo original dos registros especiales para estos fines. El registro de instruccién (IR) y el contador de programa (PC). A continuacién se muestran los métodos encargados de cichos cicls. nterface Processor ( pe primaria y se coloca en el IR 7 El ciclo de Fetch va al BC va a la direccién que apunta @ stince TR = HeMPC) ~Incrementa PC ” public void fetchinstraction (Memory ms JH* 01 ciclo de ejecucién, dorde 1a instrucciéa ee dacodifica y 9 wjecut Bie clo de Ejecucién tiene que ir a Memoria rejecuta instruceié public void exacinatruct ion (is La idea de mostrar las interfases y no su implementacién, es que si se hubiera modelado otro tipo de maquina, muy probablemente el funcionamiento de estos ciclos cambiaria (por ejemplo tuna arquitectura RISC que usa pipelining); sin embargo la implementacién se puede ver en el apéndice correspondiente. La URM incorpora a su funcionamiento un nimero ilimitado de registros, pero en procesadores reales, estos registros son limitados (acumuladores, registros de segmento, de pila, de cédigo, etc.) por lo que debe respetarse esta funcionalidad, aunque ajusténdola a un numero de registros variable y finito (lo cual permitira variar la configuracién del modelo). De hecho en el simulador de URM original también se limité el nimero de registros por cuestiones practicas, ues los programas que se disefiaron en ese entonces eran muy sencillo. En cuanto a la memoria, esta puede modelarse como un arreglo, donde cada celda de memoria puede contener una instruccién y sus parémetros. Por tanto, el acceso a la memoria es de forma 7Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar lineal, donde el indice del arreglo es equivalente a una direccién (celda) de memoria. Este ‘acceso, implica la lectura y escritura de datos en memoria. Aunque no forman parte explicitamente del modelo, se requeriré implementar un par de instrucciones para estos fines (P.e}. READ/WRITE, GET/SET, IN/out, LOAD ax,dit/LOAD dir,ax, etc.) interface Menozy ( Public void setMentec{int adr, Object value); Public Object getMemloc {int adr}; Public void showem() En el simulador se cuenta con un genérico de estas funciones, y una implementacién especifica para la memoria de la URM. 3.5.2 El software: SOM En lo que respecta al software, en especifico al sistema operativo de esta méquina, hay dos alternativas: 1. Codificar el sistema operativo en cédigo del modelo simulado. 2. Crear un médulo que se encargue de las funciones propias del sistema operativo. ‘Como se mencioné al principio, lo que se quiere es un sistema operativo minimo, pero... 2qué es eso? En concreto, es una pieza de software que permita cargar un programa a la memoria del modelo y que el procesador lo ejecute. Figura 3.7 Modelo del simulador con un cargador de programas. 8Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Si toméramos la primera opcién, lo primero que salta a la vista es que como el modelo solo consta de 4 instrucciones, el conjunto de instrucciones tendria que ser ampliado para permitir el acceso al disco, controlar dispositives, mostrar resultados en un dispositive de salida, etc. Aunque puede hacerse, el modelo se convertiria en un nuevo procesador, y en ese caso seria mejor emular un procesador con las instrucciones suficientes como para implementar un SO completo, EI segundo enfoque es igualmente valido, pues si el mismo simulador implementa el modelado de las funciones de nuestro SO minimo, el resultado de la simulacién es el mismo. Esta opcidn es la que se ha implementado. ‘Tomar esta decisién implica algunas consideraciones extra, como: = Que la direccién de carga de programas, serd el inicio del arreglo que se use. Esto se interpretaria como que el SO ya estd cargado en memoria, y esa drea esté protegida contra el acceso de otros programas. = Que el SO implemente funciones de acceso a dispositivos, aunque estos no formen parte explicita del modelo. La entrada/salida estandar es equivalente a que el simulador cuente con un monitor, y el acceso a los archivos es equivalente a contar con dispositivos y sus respectivos manejadores. De esta forma el SOM tendria todas las caracteristicas de un monitor residente, uno de los primeros SOs, las cuales pueden extenderse para implementar el procesamiento por lotes (batch), para lo que se debe incluir un JCL (Job Control Language). E1 ICL propuesto es el siguiente: * LOAD - carga un programa RUN ejecuta un programa * £0) - Fin del trabajo (End Of Job) + LDBATCH - Carga un archivo con comandos para procesarlos en lote * SHUTDOWN - Apaga el SO El modelo solo ejecutara un programa a la vez, por lo que la administracién de procesos no fue implementada. Ademas con la simplificacién del acceso a memoria tampoco se necesita un administrador de memoria, aunque pudiera ser til si se quisiera expandir la memoria base del modelo. ELSOM esta compuesto de las clases: > Loader, se encarga de cargar los programas desde su archivos a la memoria para su ejecucién. JCLinterpreter, se encarga de interpretar los comandos JCL. Monitor, esta compuesta por Loader y JCLinterpreter y se encarga de cargar un programa o un conjunto de programas en memoria para luego ejecutarlos, en base a Una secuencia de comandos ICL. v v 79Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Figura 3.8 Modelo del simulador con un SOM para una URM modificada, basado en el concepto de un monitor residente. Figura 3.8a Ejecucién del simulador 80Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar ‘Aunque sin incorporar el manejo de interrupciones, disposttivos, etc., este primer disefio es lo bastante ilustrativo como para entender lo que hace un sistema operativo, y como codifcarlo (a un nivel muy basico) En la siguiente seccién se comentan algunos de los elementos que no han sido considerados en el simulador, pero podrian ser modelados para indluir los aspectos del manejo de pero por el momento eso no esté incluido en la implementacién del apéndice B. 3.5.3 Consideraciones para el modelado de dispositivos de E/S® Uno de los elementos basicos de cualquier computadora, son sus dispositives de entrada y salida (E/S). Aunque en la seccién anterior la E/S de datos no era explicita en el modelo, estaba implicita en las funcionalidades del lenguaje. En el caso de la entrada de datos, el método runProgram() de la clase TestSimulator, captaba las instrucciones del Lenguaje de Control de Trabajos, a nivel de instrucciones en Java (hardcoded). oo jcessot pnew URMProcessor(}; //creanda tn nuevo procesador oravemory (20) 4 de inet Wis En el caso de la salida, la instruccién System.out.printin() hacia las veces de un dispositive de despliegue (monitor), permitiéndonos ver el resultado de la ejecucién del programa. Incluso el sistema de archivos también se vio encapsulado, y tampoco forma parte del modelo explicitamente. ‘Aunque la abstraccién es valida, y no impidié que el modelo se desarrollara hasta obtener un prototipo funcional, la verdad es que se supone que parte del trabajo del sistema operativo es controlar los dispositivos de E/S de la computadora, por lo que si no los tomamos en cuenta, el modelo del SO quedard incompleto, y no podrén apreciarse los detalles relacionados @ este servicio, Para mejorar el modelo propuesto, seré entonces necesario incluir el sistema de £/S en el simulador. Puede resumirse de lo expuesto en la seccién 1.4.2, que los elementos a tomar en cuenta so = El dispositive © Obras consultadas: (3.14] 81Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar + Elcontrolador del dispositive ‘+ El sistema de interrupciones Esto implica las siguientes consideraciones: a. Modelar un ivo abstracto, con un protocolo de mensajes que sea aceptado por cualquier implementacién de un dispositive espectico. El dispositive genérico deberé prover como minimo la lectura y escritura de sus datos, asi como su configuracién e identificacién, Esto seré ampliado después por las implementaciones especificas, pero debe tomarse en cuanta que el protocolo de mensajes puede verse ampliado, segin el tipo de dispositive (un monitor es mucho mas complejo que un teclado en su funcionamiento e interfaz). b. Modelar el concepto de controlador de dispositive. Todo dispositive se conecta al bus por medio de un controlador. Ademés, cada controlador tiene un buffer local, de donde el CPU recoge y envia datos. ©. Modelar un sistema de interrupciones genérico que pueda ser aprovechado por implementaciones de arquitecturas especificas. Los principales elementos del sistema de interrupciones son: - Las interrupciones, que notifican al CPU de una operacién o llegada de nuevos datos. ~ Las rutinas de servicio de interrupcién (ISR), que son los procesos que se ejecutan cuando llega una sefal de interrupcion y el CPU debe atenderla, = El vector de interrupciones, que es una tabla en memoria con las direcciones de las ISRs con que se cuenta. Debe tomarse en cuenta que: - las ISRs son instaladas en el vector por el sistema operativo; - el dispositive que interrumpe envia un numero por el bus de datos, el cual sirve de indice en el vector de interrupciones para que el CPU pueda ejecutar la ISR adecuada, + existen diferentes tipos de eventos: ‘+ Interrupciones de hardware, por sefiales de los dispositivos. + Interrupciones de software (llamadas al sistema; excepciones) por medio de instrucciones especificas del procesador. y cada evento activa una ISR diferente; - el control de interrupciones puede ser sincrono (el SO espera a que la E/S termine) o asincrono (e1 SO continua su ejecucién mientras la E/S se lleva a cabo). d. Puede tenerse en cuenta el mecanismo de acceso directo a memoria (DMA), por medio del ual los dispositivos tienen acceso a la memoria principal sin necesidad de que el CPU intervenga. Ahora hay que revisar si el modelo actual permite la comunicacién entre los dispositivos y el CPU. Puesto que todo lo anterior no fue considerado desde un principio, es casi seguro que se tenga que modificar una buena parte de la estructura del modelo. 82Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Lo que se mantendrd en el modelo es la proteccién del SO y los programas de usuario como tuna abstraccién, puesto que el SO forma parte de la implementacién del simulador no habré que implementar ese detalle. 3.5.4 Resultados La estrategia para la construccién del modelo de simulacién consistié en modelar los principales servicios de administracién de los sistemas operativos (procesos, memoria y dispositivos), para después integrarlos en diferentes configuraciones, esperando que la tarea de integracién arroje problemas y consideraciones que aporten soluciones y experiencias interesantes para la comprensién del disefio e implementacién del simulador. ‘Aunque al principio se habia planteado solo codificar los algoritmos y médulos que son importantes para los sistemas basados en niicleos modulares (los mas difundidos actualmente), la simulacién de cada una de estas partes, y del hardware relacionado @ su funcionamiento, ha dado como resultados algunas configuraciones similares a los primeros sistemas (sencillos pero muy ilustrativos). Lo positivo de esto, es que se brinda al lector una perspectiva real, no sélo de como funciona un sistema operativo y como hacerlo, sino de todas las reflexiones y decisiones Que involucra su disefo. Los principales resultados de este primer experimento son: + El escoger el modelo de URM para la simulacién, no permite experimentar con programas ‘que tengan un control total sobre los recursos. Para este fin, el conjunto de instrucciones deberia ser lo més real posible, aunque para los fines de este trabajo, conviene que tenga el menor numero de elementos posibles. ‘+ El conjunto de instrucciones de la URM es suficiente para crear programas itiles, sin ‘embargo, habria que agregar instrucciones adicionales para el control de registros, accesos a memoria y recursos, etc.; por eso es que los conjuntos de instrucciones de los procesadores reales tienen tantas instrucciones. ‘+ Implementar la abstraccién de dispositivos de E/S reduce la complejidad, pues modelar dispositivos especificos, como tarjetas de red, etc, hace necesatio contar con mas elementos tesrico-practicos, + No existié una fase previa de disefio. El “tener claro” que componentes era necesario modelar, hizo que la improvisacién reinara, y al final aunque se cuenta con un modelo que funciona, hay muchas mejoras que pueden hacerse. + En este momento se hizo patente la necesidad de una metodologia clara para proceder. Podria haber usado una metodologia de ingenieria de software como RUP, 0 la que fuera, pero sin perder el foco de este trabajo de este trabajo que son los SOs, usar una metodologia tan grande para un SO como el SOM hubiera sido excesivo (aunque en general para al simulador le hubiera caido bien) + La cohesién entre las clases del simulador es muy fuerte, por lo que hacer cambios en su cconfiguracién es algo cific + Las capacidades del Bluelay y su depurador permitieron contar con una visualizacién del proceso de simulacién (primitiva pero efectiva) + Para reforzar el modelo de simulacién, es recomendable (sino indispensable) permitir que el usuario de la herramienta pueda visualizar el comportamiento del modelo, e incluso modificar ‘su comportamiento, en cualquier momento. Para ello debe considerarse agregar a los ‘elementos més significativos del modelo, la funcionalidad para que puedan desplegar su 83Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar comportamiento a través de una interfaz gréfica. Preferentemente debe permitir visualizar el modelo a nivel general, y ademas permitir el seguimiento de cada médulo que implique un servicio relevante a todo el sistema. En el paradigma MVC (Modelo-Vista-Controlador) las, entradas producidas por el usuario, el modelado del mundo exterior, y la retroalimentacién visual al usuario estén explicitamente separadas y manejadas por tres tipos de objetos, cada uno especializado en su tarea. La Vista administra la salida gréfica y/o textual a la porcién del drea de despliegue asignade a la aplicacién. El Controlador interpreta las entradas del usuario provenientes del teclado o ratén, ordenéndole al Modelo y/o a la Vista cambiar como sea apropiado. Finalmente, el Modelo maneja el comportamiento y datos del dominio de la aplicacién, responde a requerimientos de informacién sobre su estado (usualmente de la Vista), y responde a les instrucciones al cambio de estado (usualmente del Controlador). Este modelo deberd ser considerado mas adelante. Despliegue Figura 3.9 Patrén de diseito Modelo-Vista-Controlador. En los siguientes capitulos se presentarén a detalle los diversos sistemas de administracién de servicios que cominmente forman parte de un sistema operativo. La idea es que una vez que se ha mostrado que la simulacién es una herramienta itil, se continuaré usando para demostrar el funcionamiento de estos sistemas. Debo hacer notar que el enfoque de simular el hardware y el SO, es el mas completo. Sin embargo, en los siguientes tres capitulos es probable que se simulen solo los elementos relacionados a cada sistema de administracién, 0 probablemente solo se modelen puramente los elementos de administracién, sin el hardware. Ambos enfoques considero que siguen siendo validos, sobre todo para aclarar que hace cada parte y tomar a sus simulaciones como pruebas de concepto. 3.5.5. morfo-Hardware Uno de los resultados adicionales de este primer modelo de simulacién fue la idea de crear un sistema de hardware que pudiera modificarse para probar diferentes conjuntos de instrucciones. Aste modelo se le llamé morfo-Hardware. 84Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar ADAPTADORES REGISTROS BASE Figura 3.10 Esquema del modelo morfo-Hardware La idea es contar con una abstraccién genérica de un dispositive de hardware (HWDevice), de! cual se pueden derivar procesadores, memoria, y dispositivos periféricos, quienes se comunican por medio de sefiales administradas por medio de un controlador. Figura 3.11 Modelo de clases de morfo-Hardware v.0.1 Se incluyen algunos de los diagramas de clases preliminares de este modelo (figuras 3.11 y 3.12), pues a consideracién del autor esto seria de mucha utlidad si se quieren comprobar Cuestiones de portabilidad de una plataforma de hardware a otra. 85Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Figura 3.12 Modelo de clases de morfo-Hardware v.0.2 Lo interesante del modelo es que una vez que el framework quede establecido solo hay que codificar el conjunto de instrucciones del nuevo procesador; todo lo demas quedaria intacto, En fin, esta es una idea que sigue en desarrollo. 3.6 Comentarios ‘Como ya se comenté, simular el hardware puede ser una tarea exhaustiva, y dependera mucho del nivel de detalle y realismo que se desee en el simulador. Para muchos fines bastard con indluir en los modelos elementos que efectiien las operaciones basicas de los cispositivos de hardware; sobre todo si en lo que se quiere hacer énfasis, es en los componentes del sistema operative. En tal caso debe tenerse en cuenta que muchos algoritmos relacionados @ la administracién de recursos ya estén disponibles, por lo que es deseable hacer énfasis en el andlisis y visualizacién de resultados. ‘Ya que se han planteado los principales elementos para la simulacién de sistemas operativos, en los siguientes dos capitulos se planteard el desarrollo de simuladores para los subsistemas de administracién de memoria y de procesos, respectivamente. 86Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar 3.7 Obras consultadas [3.] Guide to the Java Version of the Smple Operating System ($05) Simulate. Chares Crowley. August 1997. [2.2] The Flux 05 Toolkit: Reusable Components fer OS Implementaton, “The Flux OS Kt: A Substrate for OS and Language Research fo://mances.cs uth. edu/papersfoskt-etes6-abs html [3.3] How To Write a Computer Emulator Marat Fayzulin. 1997-2000. hitpsfiwarwekomkon.orgfms/EMULS/ [sf] The SNES Devetopers Comer hitp:/femureview ztnet.com/developerscomerindexht [3.5] Emuation programmers resource http:/tvavwclassicgaming comyEPR/ [3.6] Trends in Hardware/Software Codesign Larry tag http: /wawwembedded.com (3.7) Truth, Beauty, andthe Vitual Machine David Gelenter hitp:/rumcsyale.edu/jvmsem/lectre/0922/gelerter, htm [38] Visible Vitual Machine (WWM) Page hitps/ vam eba.ar edulfacaltyiwm/ [3.9] THE UcSo P-SYSTEM MUSFUM IN THE WEST |WING OF THE JEFFERSON COMPUTER MUSEUM hp: /wawwcthreedee.com/ery/asystem/index htm [3.10) The Free Online Dictionary of Computing Elted Denis Hewe hitosifeldoe doc i acu [3.12] nacHos hips /http.cs.berkeley.edu/~tea/nacnos/ [3,12] Salsa ~ An Operating Systems Tutorial, University of Massachusetts, Amnerst hitps/fal-wwo.cs.umassedu/salsa/aboua html [3.13] A Read Map Through Nachos. Thomas Narten Department of Computer Sciences, Levine Science Research Canter, Duke Univers. nartends.duke‘edu February 3, 1997 http: /fwn.cs duke eduy/~narteny120/nachos/main/ma nt [3.24] A Designer's Assistant Too! Home Page, Computer Systems Groun . Universty of Wateroo nitp/esg.avaterce.caldptool/ [3.5] The 0S Emulation HomePage nto:/iwnw.kearey.net/mootfmany [3.6] RcOSjavea nitp:/reesjava soureeterge.net/ [3:71 ROOS java nitp:/vabfuse.cqu.edu.au/Informaton/Resources/Rea dings/RCOSjava/ [3.28] RCOS: Yet Another Teaching Operating System Ron Chemich, Bruce Jameson, Dav Jones Proceadings ofthe Fst Australasian Conference on ‘Comauter Science Education itp: /ivebfuse.cqu.edu.au/Informaton/Resources/Rea dings/RCOS javalyatof [3.29] The Design and Construction ofa Simulated Gperting System. Ron Chernicn, David Jones, Asia Paci Information Techology in Education Conference, Brspane, Juy 1994. itp: /fvabfuse.cqu.edu.au/Information/Resources/Rea Hardware. Este nivel se ocupa de los dispositives electrénicos relacionados al almacenamiento de informacién (RAM y caches de memoria). > Sistema Operativo. En el sistema operativo debe reservarse la memoria para los programas de usuario, y reciclarse cuando ya no est en uso. El SO puede dar la ilusién de que existe més memoria de la que el sistema tiene, y también que un programa puede apoderarse de toda la memoria (sistemas de memoria virtual). > Aplicaciones. Se trata de prover la memoria necesaria a los objetos y estructuras de datos de un programa, de los recursos limitados disponibles, y reciclar dicha memoria para reusarla cuando es liberada. Puesto que los programas de aplicacidn no pueden predecir cuanta memoria requerirén, necesitan cédigo adicional para manejar sus requerimientos variantes de memoria, Una de las primeras tareas del sistema operativo es organizar una estructura heterogénea de memona (resultado de las constantes presiones de los fabricantes de sistemas y dispostivos periféricos por mantener la compatibilidad con sus esquemas de memoria originales), asignando direcciones légicas a cirecciones de memoria fisica (en conjunto con el bus de memoria) y asignando varias éreas reservadas a la tabla del vector de interrupciones, memoria de video y cédigo del B10S. En la administracién de procesos, el CPU puede ser compartido por un conjunto de procesos. Como resultado de la planificacién de procesos, es posible mejorar la utiizacién del CPU y la velocidad de respuesta de la computadora con los usuarios. Sin embargo, para realizar este © Obras consultadas: [4.1] [4.2] [4.3] [4.4] [45] 96Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar incremento en el desempefio deben mantenerse varios procesos en la memoria, por lo que esta debe poder compartir. De hecho la adi racién de memoria en un sistema operativo puede definirse como: + [a tarea desempefiada por el SO y el hardware para acomodar varios procesos en la memoria principal. Su labor consiste en llevar un registro de qué partes de la memoria se estan utlizando y qué partes no (donde estén almacenados los procesos y datos), con el fin de asignar espacio a los procesos cuando estos hagan requerimientos, liberarlo cuando terminen, asi como administrar el intercambio entre la memoria principal y el disco, en el caso en que esta no pueda albergar a todos los procesos. También facilita los mecanismos de proteccién para que un proceso no invada el espacio de otros procesos. 4.2.1 Administracion manual La administracién manual de la memoria es donde el programador tiene control directo de cuando la memoria debe ser reciclada. Usualmente esto se hace por medio de lamadas explicitas a funciones de administracién de la memoria dinémica (heap), por ejemplo, malloc/free en lenguaje C; 0 por construcciones del lenguaje que afecten el stack (como las variables locales). La principal caracteristica de la administracién manual de memoria es que provee al programa de tna forma de expresar “aqui esté este trozo de memoria; ya termine de usarlo’. El administrador de memoria no recida ninguna parte de la memoria sin tal instruccién. Las ventajas de la administracién manual de memoria son + Puede ser mas facil para el programador entender exactamente lo que esté pasando; + Algunos administradores manuales tienen mejor desempefio cuando hay poca memoria. Las desventajas de la adminisracién manual son: + El programador debe escribir mucho cédigo para hacer mantenimientos repetitivos de la memoria; * La administracién de memoria debe formar una parte significativa de cualquier médulo de interfaz; + La administracién manual por lo general requiere mas sobrecarga de memoria por objeto; + Los errores (bugs) en la administracién son comunes. Es muy comtin para los programadores que se encuentran con un administrador manual ineficiente o inadecuado, escribir cédigo para duplicar el comportamiento de un administrador de memoria, ya sea alojando grandes bloques partiéndolos para usatios, o reciclando los bloques internamente. Tal cédigo se conoce como subalojador (suballocator). Los subelojadores pueden tomar ventaja del conocimiento especial del comportamiento del programa, pero son menos eficientes que arreglar el alojador. Los subalojadores pueden ser ineficientes 0 ineficaces a menos que un experto en administracién de memoria lo implemente. 97Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Los siguientes lenguajes usan principalmente administradores de memoria manuales en varias de sus implementaciones, aunque algunos tienen extensiones para recoleccién de basura: Pascal; Cobol; Fortran; Algol; C; C4 4.2.2. Administracién automatica La administracién automatica de la memoria es un servicio que puede ser parte de un lenguaje 0 una extensién, que autométicamente recicla la memoria que un programa no usaré mas. Los administradores automaticos de memoria (conocidos cominmente como recolectores de basura, o recolectores) usualmente hacen su trabajo recicdando bloques que son inalcanzables desde las variables de un programa (es decir, bloques que no pueden alcanzarse siguiendo los apuntadores). Las ventajas de la administracién automatica son + El programador es liberado para trabajar en el problema que esté resolviendo; + Las interfases de médulos son mas limpias; + Hay menos bugs de administracién de memoria, + La administracién es més eficiente. Las desventajas son: + La memoria puede ser retenida porque es alcanzable, pero no serd usada de nuevo; + Los administradores automaticos tienen (actualmente) una disponibilidad limitada. La mayoria de los lenguajes modernos usan administracién de memoria automatica: Dylan, Erlang, Haskell, Java, Lisp, Perl, Prolog, Python, Scheme, Smalltalk, etc 4.2.3 Esquemas de Administracion® Por mucho, el esquema més sencillo de administracién de memoria es: NINGUNO. El usuario tiene a su disposicién el hardware y tiene control completo sobre el espacio de direcciones de la maquina. Esto tiene sus ventajas: ‘+ provee maxima flexibilidad al usuario, pues se puede controlar el uso de la memoria como se desee; + maxima simplicidad; + 0 se necesita soporte de hardware adicional para la administracién de la memoria; + se tiene la capacidad de ejecutar un solo proceso; + NO se necesita de un sistema operativo, Este esquema es usado solamente en sistemas dedicados donde los usuarios requieren flexibilidad y se requiere de rutinas de soporte propietaria, © Obras consultadas: (4.10] 98Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Pero ademas esto tiene sus limitaciones: NO PROVEE NINGUN SERVICIO; es decir que aunque el usuario tiene control total sobre la computadora, el SO no tiene: + control sobre las interrupciones, ‘+ ni mecanismos para llamadas a procesos o errores, + yningin espacio para proveer capacidades de multiprogramacién. Por lo anterior sera necesario explorar esquemas que permitan prover servicios a las aplicaciones y al sistema operativo. . Monoprogramacién sin intercambio® La forma més simple de administrar la memoria es ejecutando sélo un programa a la vez, que comparta la memoria con el sistema operativo (el cual esté residente en la memoria alta 0 baja, dependiendo de donde se cologue el vector de interrupciones), Texto 80. Divers Date Divers Texto. Datos sack stock stack Drivers Datos so. Texto 50. Figura 4.6 Exquemas de organizacién de memoria con manejo de dos particiones. En el esquema de monoprogramacién por lo general, el SO esté en la parte baja, los programas de usuario se cargan arriba, y un drea en la parte superior se reserva para manejadores de dispositivos, etc. (fig. 4.6). Un caso de esto es MS-DOS. Cuando un usuario ejecuta un comando, el sistema operative carga el programa correspondiente en la memoria, y lo ejecuta. Cuando el programa termina, el sistema operativo solicita un nuevo comando y carga el nuevo programa en la memoria, sobrescribiendo el anterior. La organizacién fisica bajo este esquema es muy simple: El sistema operativo se ubica en las localidades superiores 0 inferiores de la memoria, seguido por algunos manejadores de dispositivos (drivers). Esto deja un espacio contiguo de memoria disponible que es tomiado por los programas del usuario, dejando generalmente la ubicacién de la pila (stack) al ultimo, con el objetivo de que ésta pueda crecer hasta el maximo posible. Bajo este esquema no se requieren algoritmos sofisicados para asignar la memoria a los diferentes procesos, ya que éstos son ejecutados secuencialmente conforme van terminando. Obras consultadas: [4.11] 99Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar De esta forma solo se puede ejecutar un programa a la vez y entonces se hace un mal uso del procesador y de la memoria, pues usualmente los usuarios no ocupan todo el espacio disponible. Otro inconveniente es que no se puede correr un programa mds grande que la memoria disponible sin recurrir a recubrimientos (overlays). Ademés se requiere de mecanismos de proteccién para proteger al sistema operativo contra los programas del usuario. Multiprogramacién con partic jones fijas La forma mas simple de obtener multiprogramacién es dividiendo la memoria en 1 particiones fijas, de tamafios no necesariamente iguales (fig. 4.7). Puede haber una cola de trabajos por particién, o bien una sola cola general. En el primer caso, cuando llega un trabajo, se pone en la cola de la particidn mas pequefia en la que todavia quepa el trabajo. Si llegan muchos trabajos pequefios podria pasar que, mientras las colas para las particiones chicas estan llenas, las particiones grandes quedan sin uso. En el caso de una sola cola, cada vez que un programa termina y se libera una patticién, se escoge un trabajo de la cola general. Cémo escoger? ‘Manejo de Memoria con 0 parlelones fas 200 Programas 300 @ nr Figura 4.7 Administracién con particiones fijas Dentro de sus ventajas se pueden mencionar las siguientes: = Su administracién es relativamente simple, pues para guardar informacién del estado del recurso se debe tener un registro de cada zona (libre u ocupada).. - La proteccién entre usuarios se puede realizar mediante el mecanismo de llaves de memoria © utilizando el registro base y la longitud de la zona. ‘Algunos de los inconvenientes que presenta este modelo, son los siguientes: = Se hace una mala utilizacién de la memoria debido a la poca flexibilidad del método. = Es complicado correr programas mas grandes que el tamafio de la zona. « Se presenta fragmentacién interna. Este fenémeno ocurre cuando un proceso no ocupa toda la memoria asignada y sin embargo el espacio libre no puede ser utilizado por ningun otro proceso. 100Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Particiones de Longitud Variable El método de particiones de longitud variable consiste en que la memoria se divide en bloques de diferente tamafio de acuerdo a las necesidades del usuario (fig. 4.8). Una gran ventaja es su flexibilidad, pues permite definir bloques de! tamafio requerido, terminando as{ con la fragmentacién interna y permitiendo hacer un mejor uso de la memoria y por ende del procesador. Memoria can Figura 4.8 Administracién con particiones variables Sin embargo, presenta algunos inconvenientes. Al partirse la memoria en bloques de tamafio diferente, puede ocurrir que el bloque mas grande no pueda contener un programa dado, a pesar que la suma de los espacios libres sea mayor que el tamafio del programa, A esto se le denomina fragmentacién externa. Por ejemplo, si llegase un nuevo proceso solicitando un espacio de 6 unidades de tamefio, no podria asignérsele, pues no hay un espacio contiguo en la memoria de ese tamafio, a pesar de que la suma de los tamafios de los espacios libres es mayor que 6 unidades . Para solucionar este problema, se puede recurrir a realizar una compactacién de la memoria, siempre y cuando se cuente con relocalizacién dinamica. Este procedimiento puede ser muy costoso en tiempo. ‘+ Appesar de que para ejecutar un programa solo se necesita tener cargado una parte de él, en este modelo se hace necesario tener todo el cédigo en memoria, ‘+ La administracin de la memoria no es tan sencilla como en el caso de particiones fjas. La proteccién de la memoria entre los diferentes usuarios se realiza mediante el mecanismo de registro base-registro limite. E\ registro base guarda la direccién donde inicia el bloque de memoria asignado al usuario y el registro limite, la direccién donde termina. Todas las direcciones del programa serén entonces un desplazamiento con respecto al registro base. Si Por alguna razén, se encuentra una direccién que sobrepase al registro limite, se produce un error en el direccionamiento, (puesto que se estaria referenciando una directién que puede pertenecer al espacio de otro usuario), se produce una interrupcién y el sistema toma el control. La representacién de las zonas libres y ocupadas y su administracién representan un problema mayor. lolDisedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar . Registro del Uso de la Memoria El registro del uso de la memoria es un problema mayor en la asignacién por particiones de longitud variable, ya que las estructuras que deben mantenerse cambian dindmicamente, Hay 2 formas bésicas para llevar un registro del uso de la memoria: a) Administracién de la memoria con mapas de bits. Con un mapa de bits la memoria se divide en unidades de asignacién. A cada unidad de asignacién le corresponde un bit en el mapa de bits, el cual toma el valor de cero (0) si la unidad esté libre y de uno (1) si est cocupada (fig. 4.9).. Figura 4.9 Administracién con mapa de bits” El tamafio de la unidad de asignacién define qué tan grande seré el mapa de bits, Si la unidad de asignacién es pequefia, el mapa de bits seré mayor, caso contrario ocurre si la unidad de asignacién es grande. Sin embargo, si se define demasiado grande puede generar problemas de fragmentacién interna. Cuando un proceso, solicta un espacio de tamafio unidades, el sistema debe buscar una cadena de {bits de ceros consecutivos. b) Administracién de la memoria con listas ligadas. Otra forma de mantener un registro de la memoria es mediante una lista ligada de los segmentos de memoria asignados o libres, en donde un segmento puede ser un proceso o un hueco entre dos procesos (fig. 4.10). Figura 4.10 Administracién con listas ligadas* " Imagen reproducida de [4.5] " Imagen reproducida de [4.5] 102Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar Esta lista puede estar ordenada por direcciones en cuyo caso la actualizacién de la misma al terminar un proceso es casi que inmediata. Un proceso que termina tiene por lo general dos vvecinos (uno por arriba y uno por abajo), a menos que se encuentre en algtin extremo de la memoria Cuando los procesos y los huecos se mantienen en una lista ordenada por direcciones, se pueden utilizar diversos algoritmos para asignar la memoria para un proceso de reciente creacién. Se supone que el administrador de memoria conoce la cantidad de memoria a asignar. Entre ellos estan + First Fit 0 el Primero en Ajustarse. El administrador de memoria revisa toda la lista de segmentos hasta encontrar un espacio lo sufidentemente grande. El espacio se divide entonces en dos partes, una para el proceso y otro para la memoria no utlizada. Este algoritmo es répido, puesto que busca lo menos posible, + Siguiente en Ajustarse: Funciona de la misma forma que el anterior, con la diferencia que mantiene un registro del lugar dénde se encuentra un hueco adecuado. La siguiente vez que se le llama, comienza a buscar desde el punto donde se detuvo, en lugar de comenzar a buscar siempre desde el inicio. + Best-Fit o el Mejor en Ajustarse: Busca en toda Ia lista y toma el minimo hueco adecuado. En lugar de asignar un hueco grande, intenta encontrar un hueco més cercano al tamafio necesario. + Elpeor ajuste: Toma siempre el hueco més grande disponible, de forma que el hueco resultante sea lo suficientemente grande para ser ti Estos cuatro algoritmos pueden agilizarse si se tienen dos listas independientes, una para los procesos y otra para los huecos. De esta forma todos ellos, pueden limitarse a inspeccionar la lista de huecos y no la de los procesos. Sin embargo, el aumentar la velocidad implica que la complejidad se aumenta y la velocidad al liberar la memoria se aumenta, ya que un segmento liberado, debe ser liberado de la lista de procesos y adicionado a la lista de huecos. Otro algoritmo de asignacién es el de ajuste répido, que consiste en tener listas independientes para algunos de los tamafios que se solicitan con mayor frecuencia, Si se solicita un espacio de tamafo tipico (de los més frecuentes) se busca primero en tales listas. Igual sucede si se libera, se adiciona a una de ellas. Esto faciita la administracién de la memoria puesto que se van a tener espacios libres de tamafios comunes en una lista, lo que facilita su bésqueda. Sin embargo el mantenimiento de las listas también es costoso en tiempo. Intercam! de procesos entre memoria y disco La memoria es un recurso limitado en el sistema el cual va ha hacer posible que nuestros programas funcionen. Cualquier programa que se quiera ejecutar debe ser previamente cargado en memoria y esto hace que los SOs deban disefiar buenos algoritmos para aprovechar al méximo este recurso. Para la gestién de memoria existe dos sistemas que se pueden diferenciar claramente: los que durante la ejecucién intercambian procesos entre la memoria principal y el disco, y los que no. Los segundos como es de suponer son los mas sencillos. 103,Disedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar a, Sistemas sin intercambio ni paginacién. En estos sistemas la memoria que tenemos disponible para ejecutar nuestros programas, incluyendo el SO, es le memoria fisica que poseemos. Este método de gestién reduce mucho las posibilidades en cuanto a tamafio de los programas a ejecutar. Dentro de esta forma de gestién de memoria existen también diferentes estrategias. La mas sencilla es la de tener un solo programa en memoria ejecuténdose que la ocupe toda, pero este método es nefasto porque el aprovechamiento de la memoria es minimo. La otra forma es tener particiones de la memoria de tamafio fijo de forma que puedan coexistir varios programas en la memoria principal. Asi se da soporte para la multiprogramacién pero se generan 2 problemas: la reubicacién y la proteccién Estos dos problemas estén intimamente ligados y consisten en que los programas pueden saltar a direcciones de memoria que no pertenecen a su érea de direcciones. Estos problemas se soluciona dotando a la maquina registros especiales llamados registro base y registro limite, de forma que el programa genera direcciones virtuales y para acceder a la direccién real se Utiizan estos registros. La direccién de memoria se calcula sumando al a direccién virtual la direccién contenida en el registro base y sélo puede llegar a la posicién indicada en el registro limite. b. Sistemas con intercambio y pa: Estos sistemas a diferencia que los anteriores van a permitir que programas que posean un ‘tamafio mayor al de la memoria puedan ejecutarse ya que el tamafio de la memoria del que disponemos es mayor que el tamafio real. El concepto de intercambio ya se ha explicado anteriormente y consiste en intercambiar procesos entre la memoria central y el disco. Los sistemas que utilizan este método no suelen dividir la memoria en particiones fijas sino que las patticiones de la memoria se van creando segin vayan apareciendo y desapareciendo procesos nuevos. De esta forma el aprovechamiento de la memoria es mejor, pero complica la insercién y desocupacién en la memoria Intercambio (Swapping) El esquema de intercambio es itil en los sistemas de tiempo compartido. En estos sistemas cuando se ha finalizado una transaccién con el usuario, se entra en un periodo de espera relativamente largo en términos del tiempo del procesador, mientras el usuario responde. Durante este tiempo, se puede cargar un nuevo programa en la zona asignada al usuario. Para ello, se requiere transferir el primer programa a la memoria auxiliar (disco) y cargar un nuevo programa en la zona. Cuando este finalice su transaccién, se puede volver a cargar el primer programa (fig. 4.11). Si en un sistema interactive no es posible mantener a todos los procesos en memoria, se puede usar el disco como apoyo para extender la capacidad de la memoria: pasar procesos ‘temporalmente a disco. loaDisedo y simulacion de sistemas operativos ~ Eugenio Jacobo Hemndee Valdelamnar may pS Figura 4.11 Intercambio EI sistema operative mantiene una tabla que indica qué partes de la memoria estén desocupadas, y cudles en uso. Las partes desocupadas son hoyos en la memoria; inicialmente, toda la memoria es un solo gran hoyo. Cuando se crea un proceso 0 se trae uno del disco, se busca un hueco capaz de contenerlo, y se pone el proceso all Las particiones ya no son fijas, sino que van cambiando dinémicamente, tanto en cantidad como en ubicacién y tamafio. Ademas, cuando un proceso es pasado a disco, no hay ninguna garantia de que vuelva a quedar en la misma posicién de memoria al traerlo de vuelta, de manera que es imprescindible el apoyo del hardware para hacer ligadura en tiempo de ejecucién. Si los procesos pueden crecer, conviene reservar un poco mas de memoria que la que estrictamente necesita al momento de ponerlo en memoria. Al hacer swapping, no es necesario guardar todo el espacio que tiene reservado, sino sélo el que esté usando. Otro punto que hay que tener en cuenta al usar swapping, es la E/S que pudiera estar pendiente, Cuando se hace, por ejemplo, input, se especifica una direccién de memoria donde se va a poner lo que se lea desde el dispositive. Supongamos que proceso A trata de leer cel disco hacia la direccién ¢, pero el dispositivo esta ocupado: su solicitud, por lo tanto, es encolada, Entretanto, el proceso Aes intercambiado a disco, y la operacién se completa cuando Anno esté en memoria, En esas circunstancias, lo leido se escribe en la direccién , que ahora corresponde a otro proceso. Memoria virtual® En tiempos pasados cuando un programa era mas grande que el tamafio de la memoria, este debia dividirse en médulos 0 partes e irse cargando a medida que se iban necesitando (recubrimientos). Este trabajo correspondia al programador y esto ademas de ser un trabajo engorroso implicaba pérdida de tiempo. Posteriormente se creé un mecanismo para encargarle este trabajo en su totalidad al sistema operativo. La necesidad cada vez mas imperiosa de ejecutar programas grandes y el crecimiento en oder de las unidades centrales de procesamiento empujaron a los disefiadores de sistemas operatives a Jmplantar un mecanismo para ejecutar autométicamente programas mas grandes que la memoria real disponible, esto es, de ofrecer memoria virtual. © Obras consultadas: [4.12] [4.13]