Raúl R. Peralta et al., III Congreso Colombiano de Computación, Medellín, Abril de 2008

Transcripción

1 Raúl R. Peralta et al., III Congreso Colombiano de Computación, Medellín, Abril de Una Aplicación para el Aprendizaje de Sistemas Operativos (Medellín, Abril de 2008) An Application for Learning Operating Systems (Medellin, April 2008) Raúl R. Peralta M., MSc. 1, Félix M. Kanazawa M., Ing. 2 y Pedro A. Rodríguez G., Ing. 3 1 y 3 Universidad Católica de Santa Maria de Arequipa Perú 2 Facultad de Politécnica, Universidad Nacional de Asunción Paraguay 1 rperalta57@hotmail.com, 2 felix.kanazawa@gmail.com y 3 prodrigu29@yahoo.es Recibido para revisión 28 de Noviembre de 2007, aceptado 14 de Febrero de 2008, versión final 28 de Febrero de 2008 Resumen El estudio de los Sistema Operativos (OS s) demanda mucho tiempo y esfuerzo debido a la gran cantidad de algoritmos y el elevado número de líneas de código (LOC) que componen los mismos. Adicionalmente, existe una gran variedad de algoritmos que pueden ser elegidos para programar las principales estructuras de un OS. Este articulo presenta el diseño e implementación de una Aplicación para Aprender Sistemas Operativos (ALOS). La aplicación permite en tiempo real observar el funcionamiento y cambiar la política de administración de la Unidad de Administración de Memoria (MMU). De esa manera los estudiantes de OS s comprenderán mas rápidamente y claramente los conceptos relacionados a la administración de memoria en un OS. Palabras Clave Sistemas Operativos y Aplicaciones de Maquinas Virtuales Abstract Learning an Operating System (OS) is time consuming and demands a lot of effort since the lines of code (LOC) and algorithms are higher in number. In addition, there are a lot of ideas to implement the main strutures of the OS. This paper presents an Application for Learning Operating Systems (ALOS) an interactive tool that in real time allows students to see how the Memory Manegment Unit (MMU) is working and allows students to change the memory administration policy. In this fashion, the users can understand and learn the OS fundamentals and MMU principles in an efficient manner. Keywords Operating Systems and Virtual Machines applications U I. INTRODUCCION N Sistema Operativo actúa cómo mediador entre el usuario de una computadora y el hardware de la computadora con el propósito de brindar un entorno en el que el usuario pueda ejecutar programas de manera simple y eficiente [1]. De acuerdo con [2], el corazón de los OS s está formado por las llamadas al sistema ( system calls ) y sus principales unidades o estructuras son: la unidad de manejo de procesos, la unidad de manejo de dispositivos de entrada y salida (I/O), la unidad de manejo de memoria y la unidad de manejo de archivos. Por otro lado, el estudio de estos temas no es tarea fácil debido a que cada una de las estructuras tiene una variedad de algoritmos que pueden usarse y el número de líneas de código es elevado. Desde luego, que es posible encontrar Sistemas Operativos cómo el caso del MINIX Versión 3 (MINIX 3) [3] que ha sido diseñado con fines de estudio. Sin embargo al igual que la mayoría de OS s, MINIX 3 solo implementa una estrategia o algoritmo en cada una de las unidades que lo componen. Adicionalmente, [1] define que existen Máquinas Virtuales (VM) que abstraen el hardware de una sola computadora dentro de diferentes entornos de ejecución, creando así la ilusión de que cada entorno corre en una computadora privada. Son ejemplos de VM s: VMWARE [4], BOCHS [5] y QEMU [6]. Las VM s pueden comunicarse entre ellas haciendo uso de interfaces cómo discos virtuales flexibles [5] o sockets. Esta última opción provee comunicación en tiempo real. Con el objetivo de simplificar el aprendizaje de los OS s III Congreso Colombiano de Computación, Medellín, Abril de 2008

2 Raúl R. Peralta et al., III Congreso Colombiano de Computación, Medellín, Abril de proponemos una herramienta que muestre el funcionamiento de la MMU de MINIX trabajando bajo diferentes políticas de administración de memoria. El control de MINIX se lleva a cabo desde otro sistema operativo (WINDOWS XP [7] o FEDORA [8]) mediante mensajes que serán transportados por medio de un socket y ambos OS s correrán en la misma computadora haciendo uso de una VM. El resto de éste articulo organizado de la siguiente manera. En la segunda sección se muestran los trabajos previos relacionados a MINIX y BOSCH. La tercera sección presenta el diagrama de bloques de ALOS. En la cuarta sección se presenta el detalle de la implementación de la herramienta. La discusión de los experimentos se muestra en la quinta sección. Finalmente, las conclusiones y el trabajo futuro están en la sexta sección. A. MINIX 3 II. TRABAJOS PREVIOS MINIX fue elegido cómo plataforma para ALOS debido a las siguientes razones: - MINIX fue diseñado y escrito para la enseñanza de los conceptos presentes en OS s por tanto el código es abierto y está explicado en el libro texto de los autores en [2] y también existe documentación su website [3]. - El reducido LOC hacen de MINIX 3 un caso de estudio de OS s. De acuerdo con sus creadores el código fuente puede ser cubierto en un semestre de estudio y es viable implementar otras políticas de administración en cualquiera de las estructuras del OS. - MINIX cumple la norma POSIX, tiene una pila TCP/IP, soporta X-WINDOWS y corre aplicaciones que sean programadas en C/C++, Java, Perl y Python. - Finalmente, es un OS con licencia BSD [9] que permite a los usuarios hacer todo tipo de modificaciones y distribuciones siempre y cuando se mantengan los créditos de los autores originales. Desde luego que no todas son ventajas ya que restan muchos retos que superar. El principal problema en MINIX3 es que tiene bajo desempeño debido al tiempo que demora en pasar los mensajes entre las unidades (estructuras) y las aplicaciones de usuario; otro problema es que los dispositivos que soporta son orientados a computadoras tipo desktop. Actualmente MINIX solo puede manejar pocas tarjetas de red y no es capaz de manejar dispositivos tipo SCSI. B. BOCHS BOCHS es definido en [5] cómo un emulador de una computadora personal (PC). Puede emular una CPU Intel x86 con sus dispositivos de entrada y salida. Es cómo tener su propia PC dentro de otra PC. BOCHS puede correr sobre OS cómo WINDOWS XP/2000 o LINUX y es capaz de correr MINIX en su interior. Dentro sus características podemos mencionar: - Emulación de Pentium III. - Tarjeta de red NE Tarjeta de video Cirrus SVGA. - Librerías nogui, rfb, sdl, term X para monitores en LINUX. - Librerías nogui, rfb, win32 para monitores en WINDOWS. La principal desventaja es la velocidad de emulación. De acuerdo con Kevin Lawton, su creador, la velocidad de emulación es cercana a 1.5 MIPS. Sin embargo al igual que MINIX el código del emulador es abierto y gratuito. C. Herramientas similares MINIX y el libro texto de sus creadores mencionado en [2] es uno de los mas usados en los cursos de Sistemas Operativos a nivel de pre y post grado en el mundo. En el libro está detallado cómo introducir modificaciones al OS y existen abundantes ejercicios resueltos sobre este tema, sin embargo no conocemos de una herramienta que tenga las características mencionadas y que sea de código abierto y gratuito destinada a mejorar el aprendizaje de OS s. III. DIAGRAMA DE BLOQUES La Fig.1 muestra el diagrama de bloques de la herramienta propuesta: Fig. 1. ALOS. Diagrama de bloques ALOS modifica MINIX, La herramienta posee tres componentes en MINIX y uno en WINDOWS XP. Note que MINIX está corriendo sobre una VM, BOCHS, que a su vez está soportado por WINDOWS XP en la misma computadora. En WINDOWS XP está presente una aplicación o programa Cliente que se encarga de recibir los comandos del usuario (Control), mostrar los resultados de la acción tomada (Grafica) y transmitir mensajes a MINIX (Tx/Rx Socket). En el lado de MINIX se observa el bloque del microkernel, que no ha sufrido alteraciones, cuyo comportamiento es pasivo para ALOS pero a la vez fundamental porque es el encargado de pasar los mensajes desde la MMU al programa Servidor y viceversa. Bajo el enfoque de microkernel la MMU es un proceso que corre en el espacio de usuario sin embargo el

3 Raúl R. Peralta et al., III Congreso Colombiano de Computación, Medellín, Abril de acceso es solo posible a través del microkernel y un llamado al sistema. La mayoría de OS s tienen una sola política para la asignación de los huecos de memoria a los procesos la misma que se produce al momento de crear los procesos mediante los llamados al sistema FORK o EXECL. MINIX emplea la política del primer ajuste (FIRST-FIT) [2]. Cómo se puede apreciar en el diagrama de bloques se ha adicionado tres políticas más: mejor ajuste (BEST-FIT), peor ajuste (WORST-FIT) y siguiente ajuste (NEXT-FIT). Por tanto, un nuevo llamado al sistema fue definido para controlar la MMU (Selector), que trabaja cómo un interruptor. Dependiendo de cierto valor asume una de las cuatro posibles políticas de asignación de memoria. Adicionalmente dentro de la MMU podemos ver otro bloque llamado "Get Info" que está a cargo de reportar el estado de la MMU, específicamente proveerá información de la tabla de procesos podremos observar los valores del segmento de datos (Data Segment), segmento de pila (Stack Segment) y segmento de texto (Text Segment) así cómo la tabla de huecos, que son bloques de memoria libre que no han sido asignados a ningún proceso. ALOS tiene un módulo para controlar las políticas de administración en la MMU (Control) que funciona activando nuevos procesos (programas de prueba) y recibiendo comandos desde el usuario en WINDOWS XP (Tx/Rx Socket). IV. COMPONENTES DEL SOFTWARE Para lograr el objetivo implementamos los bloques descritos en la sección anterior de manera autónoma y después conectamos todos ellos para que trabajen juntos. 1) Tx/Rx Sockets en MINIX y WINDOW. Debido a que necesitamos intercambiar mensajes entre la computadora y la VM en tiempo real, las conexiones de red son las mejores candidatas para ser el canal de comunicaciones. Las conexiones pueden ser sobre la base de sockets TCP o UDP y ambos protocolos corren encima de IP. Ellos ofrecen la entrega de información en base al mejor esfuerzo, lo que significa que puede existir pérdida o duplicidad, o corrupción de paquetes. TCP es un protocolo confiable que tiene un mecanismo para el control de errores. Por otro lado UDP envía paquetes esperando que estos lleguen a su destino sin ofrecer un control de errores y el tamaño del paquete depende del tamaño máximo del datagrama. UDP es usado mas cómo portador en aplicaciones multimedia (audio y video) y TCP es portador para aplicaciones que transportan datos. Pese a que UDP es orientado al mensaje es la mejor opción debido a que la computadora y la VM comparten la misma capa física por lo que los errores son nulos o mínimos y evitamos la sobrecarga u overhead de TCP. La arquitectura para la conexión de red es de tipo Cliente Servidor cómo lo muestra la Fig. 1 cada vez que la interfase de usuario envía un comando o necesita información acerca del estado de MINX enviará un datagrama con el código del comando después de lo cual el Servidor responderá pero primero desarrollará alguna acción en la MMU a través de su bloque de control. 2) Selector. En la comunicación de mensajes entre los procesos MINIX emplea la estrategia de paso de mensajes cómo interfase primaria entre él y los procesos de usuario. Se ha definido una llamada al sistema, Selector, con el objetivo de colocar un valor a una variable global en la MMU denominada alos_switch. En función a dicho valor una de las cuatro políticas de administración de memoria funcionará cuando los procesos requieran memoria. Los posibles valores de alos_switch son: #define MEM_FIRST_FIT 1 #define MEM_WORST_FIT 2 #define MEM_BEST_FIT 3 #define MEM_NEXT_FIT 4 El valor por defecto es 1 que corresponde a la administración de memoria usando la política del primer ajuste. 3) Estrategias de manejo de memoria. El manejo de la memoria es similar al manejo de archivos. En ambos casos hay que lidiar con una secuencia de huecos o ranuras en las cuales los objetos pueden ser depositados y luego buscados para un uso específico. De acuerdo con [2] la Fig. 2 muestra cómo es la administración de memoria. Fig. 2. Manejo de Memoria en MINIX La memoria es fragmentada en huecos y cada uno de ellos puede estar libre u ocupado por un segmento de un proceso: datos (DATA), texto (TEXT) o pila (STACK). La figura muestra cómo los huecos son etiquetados y organizados a través de listas enlazadas. La MMU de MINIX usa dos tablas; una tabla de procesos y una tabla de huecos libres. Cuando un proceso requiere memoria para un segmento envía un mensaje a la MMU con el tamaño expresado en clicks, que son unidades de 4096 bytes. Luego la política de administración de memoria o algoritmo busca un hueco dentro de la tabla de huecos libres que sea lo suficientemente grande para contener el segmento. Luego el hueco es dividido en dos partes, una para el proceso y el resto va a dar a la tabla de huecos libres. Finalmente los punteros se actualizan. En el código de MINIX está la llamada al sistema do_allocmem que se encarga de administrar la tabla de huecos. MINIX solo implementa la política del primer

4 Raúl R. Peralta et al., III Congreso Colombiano de Computación, Medellín, Abril de ajuste (FIRST-FIT) en donde el manejador de memoria recibe una petición de memoria para un segmento y busca a lo largo de la lista enlazada de huecos hasta encontrar el primer elemento que sea lo suficientemente grande para contener el segmento y luego lo divide de la forma que se ha señalado anteriormente. En la herramienta propuesta se ha implementado tres políticas mas: o El siguiente ajuste (NEXT-FIT) que es similar al primer ajuste excepto que mantiene la posición en la cual se encontró el último hueco y la siguiente búsqueda empieza en ese punto y no desde el inicio de la lista de huecos libres, es decir que se comporta cómo una lista circular. o El mejor ajuste (BEST-FIT) busca en toda la lista y toma el hueco más pequeño que sea capaz de contener al segmento. o El peor ajuste (WORST-FIT) es similar al anterior con la diferencia que toma el hueco más grande disponible. De lo indicado en [2], adicionamos código al archivo alloc.c concretamente en las funciones alloc_mem y do_allocmem. 4) Get Info. En [2] se presenta la Fig. 3 que muestra cómo MINIX maneja la información de la memoria. **** PM Process Table **** pid = 0 name = pm TXT = DTA = STK = 18 11e 0 pid = 4 name = fs TXT = 0 11e b DTA = cc STK = 4cc 5f5 0 pid = 5 name = rs TXT = 0 5f5 2 DTA = 0 5f7 a STK = a pid = 8 name = mem TXT = 0 61c 2 DTA = 0 61e 4a STK = 4a pid = 82 name = getty TXT = 0 67f 2 DTA = 0 68b 1 STK = 4 68f 1 pid = 95 name = gsys.out TXT = DTA = STK = 13 89a e **** Holes Table **** 0 base = 681 len = base = 2d len = base = 8a8 len = base = 714 len = 1d base = 0 len = 0 Fig. 3. Información de la memoria en MINIX La figura presenta el mapa de memoria. Por un lado se tiene los huecos y por el otro los huecos asignados a los procesos. Para construir una interfase que muestra lo que sucede en el OS necesitamos interpretar los valores de ambas tablas. En particular se necesita el detalle de los segmentos de datos, y pila. Entre ellos hay un hueco y entre esos límites el segmento de datos y de pila crecen en direcciones opuestas. Para extraer la información se puede emplear el llamado a sistema GetSystemInfo (Get Info) que puede evacuar esos valores. Colocando los parámetros adecuados en GetSystemInfo conseguimos una copia de las tablas. Un ejemplo de la salida se muestra a continuación: 5) Servidor. Es el módulo que recibe las órdenes a través del socket UDP en MINIX y envía las llamadas al sistema pasando mensajes a través del microkernel. Los comandos son básicamente tres: uno para crear nuevos procesos, otro para evacuar los valores de las tablas que dan cuenta del estado actual de la MMU y uno para configurar la política de administración de memoria. V. EXPERIMENTACIÓN Una vez terminada la implementación de la herramienta se paso a la fase de experimentación en la cual se procedió a crear procesos y observar el funcionamiento de la MMU bajo diferentes políticas de administración de memoria. 1) Procesos. Un proceso es un programa en ejecución cuyos segmentos ocupan una cantidad de memoria determinada; normalmente los recursos que consumen los procesos dependen de las LOC y de los datos que manejan. Con el objetivo de mantener los programas con cantidades fijas de memoria en los segmentos que conforman los procesos emplearemos programas simples que sigan la siguiente estructura:

5 Raúl R. Peralta et al., III Congreso Colombiano de Computación, Medellín, Abril de #define CHIP INTEL #include <minix/const.h> /* CLICK_SIZE */ static char data[2*click_size]; int main() { while(1); return 0; } Cómo se puede observar en el código se ha definido una variable global llamada data que demandará al menos dos clicks para el segmento de datos. El objetivo es contar con un grupo de programas con tamaños específicos de tal forma que podamos observar cómo es la asignación de los huecos libres de memoria (cómo funciona la MMU). Por ejemplo si se corre dos veces el programa anterior, llamado alos2.c, entonces al listar los procesos obtenemos la siguiente información: pid: 139 alos2.out txt: pid: 139 alos2.out dta: pid: 139 alos2.out stk: pid: 140 alos2.out txt: pid: 140 alos2.out dta: pid: 140 alos2.out stk: La primera vez que corre alos2, PID=139, necesita cuatro clicks : uno para el segmento de texto, dos para el segmento de datos y uno para el segmento de pila. La segunda vez que corre el programa, PID=140, el proceso requiere solo tres clicks debido a que el segmento de texto o código ya está corriendo es decir los dos procesos comparten el código contenido en el segmento de texto. MINIX trata de encontrar un hueco que sea lo suficientemente grande para soportar los segmentos del programa. Es importante mencionar que los valores por defecto que emplean la mayoría de compiladores asumen 64KB para el segmento de pila. Esta condición puede ser evitada en el momento de la compilación empleando el parámetro stack (pila) cómo se muestra a continuación: cc alos2.c o alos2.out stack 4k 2) Opciones. La interfase inicial que se ha implementado trabaja en base al teclado y muestra las siguientes opciones: a:first fit b:worst fit c:best fit d:next fit e:kernel info f:tabla procesos g:hole table h:log file i:proc T1 j:proc T2 k:proc T4 l:proc T8 m:proc T16 n:r.p.f.m o:reset log z:salir Las opciones a - d son para cambiar la política de administración de memoria en la MMU. La opción e muestra información acerca del kernel. Las opciones f y g son para mostrar los valores actuales de la tabla de procesos y de la tabla de huecos. Adicionalmente se puede salvar los valores de las tablas en un archivo de tipo log o resetear el archivo haciendo uso de la opción h u o. Las opciones i - m están destinadas a cargar procesos usando las llamadas al sistema tipo FORK (si el programa corre por primera vez) y EXECL (si corre por segunda vez). Proc T1 cargará en el OS un nuevo proceso que puede usar tres o dos clicks, Proc T2 usará cuatro o tres clicks y así sucesivamente. 3) Ejemplo. Con el objetivo de ver el funcionamiento vamos a mostrar la tabla de procesos y la tabla de huecos cuando la política de administración de memoria es el primer ajuste (FIRST-FIT). El estado inicial es: base = 681 len = 5 base = 59 len = 5 base = 2d len = 2 Después de lo cual corrimos el proceso T1. Debido a que es la primera vez el número de clicks a usar es tres. La salida en la tabla de huecos quedo de la siguiente manera: HOLES: base = 681 len = 5 base = 5c len = 2 base = 2d len = 2 PROCESS: pid: 137 alostest1.out txt: pid: 137 alostest1.out dta: 0 5a 1 pid: 137 alostest1.out stk: 1 5b 1 En azul podemos ver las modificaciones. Ahora la tabla de huecos tiene dos clicks más; tres fueron usados por T1: uno para el segmento de texto en 59 (longitud de un click ), uno para el segmento de datos en 5a y uno para el segmento de pila. Luego adicionamos otro proceso de tipo T1. La tabla de huecos mostró la siguiente información: HOLES: base = 681 len = 5 base = 5c len = 2 PROCESS: pid: 137 alostest1.out txt: pid: 137 alostest1.out dta: 0 5a 1 pid: 137 alostest1.out stk: 1 5b 1.. pid: 138 alostest1.out txt: pid: 138 alostest1.out dta: 0 2d 1 pid: 138 alostest1.out stk: 1 2e 1 Ahora el segundo T1 toma el primer hueco 2d con longitud de dos. El segmento de texto esta compartido por

6 Raúl R. Peralta et al., III Congreso Colombiano de Computación, Medellín, Abril de el proceso T1 debido a que el código es reentrante. El siguiente escenario fue correr el programa T2. HOLES: base = 685 len = 1 base = 5c len = 2 PROCESS: pid: 137 alostest1.out txt: pid: 137 alostest1.out dta: 0 5a 1 pid: 137 alostest1.out stk: 1 5b 1.. pid: 138 alostest1.out txt: pid: 138 alostest1.out dta: 0 2d 1 pid: 138 alostest1.out stk: 1 2e 1 pid: 139 alostest2.out txt: pid: 139 alostest2.out dta: pid: 139 alostest2.out stk: Cambiar la política de administración de memoria altera la forma cómo se usan los huecos de memoria disponibles, la tabla de procesos desde luego sufren una modificación pero los segmentos de procesos mantienen la misma cantidad de clicks de la manera cómo se ha explicado en los párrafos anteriores. VI. CONCLUSIONES Y TRABAJO FUTURO Es posible sobre la base de una VM y un Sistema Operativo de código abierto cómo MINIX implementar una herramienta que facilite el aprendizaje de los algoritmos y también es viable mostrar cómo funciona un OS en tiempo real. MINIX es un OS que merece mayor atención por parte de profesores y alumnos por que permite conocer los fundamentos de los OS. La implementación de una herramienta similar haciendo uso de LINUX hubiera sido extremadamente difícil porque el elevado LOC y por que LINUX no sigue una política de tipo microkernel. En el futuro esperamos mejorar las interfaces de ALOS así cómo usar otra VM que tenga mejores prestaciones. Por otro lado seria interesante adicionar mas características a la herramienta de tal forma que por ejemplo se pueda probar diferentes estrategias y se muestre el trabajo de la unidad que administra los archivos (file system). [8] Fedora, A Linux based operating system Disponible en: [9] BSD, Berkeley Software Distribution Website: Raúl R. Peralta Meza, recibió sus grados académicos de: Bachiller en Ing. Electrónica, Universidad Nacional de San Agustín de Arequipa en el año 1993, Magíster en Informática, Pontificia Universidad Católica del Perú en el año 2000 y de Maestro en Ciencias en Ingeniería del Computador, Universidad de Nuevo México, Estados Unidos en el año Ha sido recipiente de la beca Fulbright en el año 2005 y una beca del Gobierno Mexicano-JICA para estudiar una especialización en Ing. Mecatrónica en el año Es catedrático en la Universidad Católica de Santa Maria de Arequipa desde el 2001 y recientemente ha sido incorporado al Programa de Ing. de Telecomunicaciones en la Universidad Católica San Pablo de Arequipa. Felix M. Kanazawa Makino, recibió sus grados académicos de: Bachiller en Ing. Electrónica, Facultad de Ingeniería de la Universidad Nacional de Asunción en el año 1993, Magíster en Gestión de Empresas, Universidad Autónoma de Asunción en el año Técnico Superior en Electrónica en la Facultad de Politécnica de la Universidad Nacional de Asunción en el año Becas en Ingeniería en Planta Externa en Fibra Óptica: NTT - JICA Suzuka Japón en el año Curso de Especialización en Ingeniería Mecatrónica CNAD Mexico D.F. Mexico en el año Por más de 10 años viene laborando en empresas de Telecomunicaciones donde se ha especializado en el diseño, instalación y mantenimiento de telefonía celular y ha participado en proyectos de ampliación e integración de redes celulares dentro y fuera de Paraguay y es Profesor Asistente en la cátedra de Electrónica Digital en la Facultad de Politécnica de la Universidad Nacional de Asunción y Líder del Grupo de Investigación en Electrónica y Mecatrónica de la Facultad de Politécnica de la Universidad Nacional de Asunción. Pedro A. Rodríguez. Gonzales, recibió su titulo Profesional en Ingeniería Electrónica y Maestrado en Ingeniería de la Producción en la Universidad Nacional de San Agustín de Arequipa en los años 1990 y 2007 respectivamente. Es docente en el Programa Profesional de Ingeniería Electrónica de la Universidad Católica Santa Maria y en la Escuela Profesional de Ingeniería de Sistemas de la Universidad Nacional de San Agustín de Arequipa. Sus áreas de interés son lógica programable y sistemas operativos. REFERENCIAS [1] A.Silberschatz, P.Baer y G.Gagne, Operating System Concepts, Seventh Edition, John Wiley & Sons, Inc Ed ISBN [2] A.Tanenbaum y A.Woodhull, Operating Systems Design and Implementation, 3/E, Prentice Hall Ed ISBN [3] MINIX 3, The MINIX Operating System Disponible en: [4] VMware, Virtualization software emulator. Disponible en: [5] BOCHS, The Cross Platform IA-32 Emulator. Disponible en: [6] QEMU, Open Source Processor Emulator. Disponible en: [7] Windows XP. Website oficial: