Trabajo De Diploma

Universidad Central “Martha Abreu” de Las Villas Facultad “Matemática-Física-Computación” Licenciatura en Ciencias de la Computación

Trabajo de Diploma

Título: Sistema Operativo Minix versión UCLV.

Autor: Dayli Suset Rojas Jiménez. Tutor: Dr. Mateo G. Lezcano Brito. Laboratorio: Informática Educativa.

Santa Clara, junio 2011 “Año 53 de la Revolución”

Dictamen.

El que suscribe, ___ , hago constar que el trabajo titulado ______fue realizado en la Universidad Central “Marta Abreu” de Las Villas como parte de la culminación de los estudios de la especialidad de , autorizando a que el mismo sea utilizado por la institución, para los fines que estime conveniente, tanto de forma parcial como total y que además no podrá ser presentado en eventos ni publicado sin la autorización de la Universidad.

Firma del autor

Los abajo firmantes, certificamos que el presente trabajo ha sido realizado según acuerdos de la dirección de nuestro centro y el mismo cumple con los requisitos que debe tener un trabajo de esta envergadura referido a la temática señalada.

___ Firma del tutor Firma del jefe del Laboratorio

Fecha

Pensamiento

"Sin su software, la computadora es un montón de metal inútil". Andrew S. Tanenbaum

Dedicatoria

A mi mamá por estar siempre apoyándome Por ser la mejor mamá del mundo.

A Darly por ser la personita más especial de mi vida.

A Ony por ser la luz que ilumina mi camino. Por ser un papá maravilloso para mí.

Agradecimientos

A mi mamá y a Ony, quienes me indujeron la ética y el rigor que me guían para transitar por la vida. Gracias por estar en todo momento a mi lado apoyándome y exigiendo de mí un mayor esfuerzo.

A mi hermana Darly, por apoyarme y confiar en mí.

A mi papá por brindarme los medios básicos que han sido de gran ayuda en el transcurso de mi carrera.

A mis tíos David y Ube por su comprensión y ayuda en los momentos más difíciles de la carrera.

A mi tutor por su asesoramiento y estímulo para seguir creciendo intelectualmente.

A mis abuelos mima y pipa, por su comprensión y ayuda durante el tiempo que le dediqué a esta tesis.

No podría dejar de mencionar a mis compañeros Sandro, Yoandy, Pupo y Morellito por su voluntad permanente de aclarar mis dudas y por su apoyo en la búsqueda de información actualizada.

No es posible agradecer, en esta cuartilla, a todas las personas que durante mi estancia en la universidad han aportado a mi conocimiento intelectual un granito de arena, lo cual no implica que su ayuda haya pasado inadvertidamente. A todas esas personas, mi más sincero agradecimiento.

Dayli Suset Rojas Jiménez Santa Clara, Cuba, Junio 2011

Índice de Contenido

Introducción ...... 1

Antecedentes ...... 1

Planteamiento del problema ...... 1

Objetivos de la investigación ...... 2

Pregunta de investigación ...... 2

Justificación ...... 2

Viabilidad ...... 3

Hipótesis de investigación ...... 3

Estructura del proyecto ...... 3

Capítulo I. Evolución de los sistemas operativos ...... 4

1.1- Introducción ...... 4

1.2-Sistema Operativo ...... 4 1.2.1- Breve historia del surgimiento del sistema operativo ...... 4

1.3-La enseñanza de sistemas operativos ...... 5

1.4-Herramientas para la enseñanza de sistemas operativos ...... 6 1.4.1- Sistemas Operativos para la enseñanza ...... 6 1.4.1.1- NachOS ...... 6 1.4.1.2- RCOS ...... 7 1.4.1.3- RCOS.java ...... 9 1.4.1.5- PintOS ...... 10 1.4.1.6- Topsy (Teachable Operating System) ...... 10 1.4.1.7- AMOS ...... 10 1.4.1.8- Xv6 ...... 11 1.4.2- Asistentes para la enseñanza de sistemas operativos ...... 11 1.4.2.1- DYNAMIX ...... 11

1.5- Características del sistema operativo MINIX 3 ...... 12 1.5.1- Estructura de MINIX 3 ...... 13

1.5.2- Aplicaciones de MINIX3 ...... 15

1.6- Resumen ...... 16

Capítulo II. Sistema operativo MINIX, transformaciones sencillas ...... 17

2.1- Introducción ...... 17

2.2- Organización del código fuente del SO MINIX 3 ...... 17

2.3- Proceso de compilación del sistema operativo ...... 20

2.4- Configuración del SO MINIX 3 ...... 21 2.4.1- Configuración de un password para el usuario root ...... 21 2.4.2- Adicionar un nuevo usuario al sistema ...... 22 2.4.3- Cambiar de nombre a la máquina virtual ...... 22 2.4.4- Mensaje de bienvenida al iniciar el SO ...... 23 2.4.5- El promt del usuario root ...... 23 2.4.6- Configuración del idioma del teclado ...... 24 2.4.7- Mensaje inicial para reflejar nuevos cambios en el SO MINIX 3 ...... 24 2.4.8- Mensaje durante el arranque del sistema ...... 25

2.5- Modificaciones al editor mined ...... 26

2.6- Resumen del capítulo ...... 28

Capítulo III. Arquitectura del MINIX. Transformaciones a sus componentes ..... 29

3.1- Introducción ...... 29

3.2- Archivos de encabezamiento comunes en MINIX 3 ...... 29

3.3- Las llamadas al sistema ...... 32 3.3.1- Adición de una nueva llamada al sistema ...... 34 3.3.2- Creación de un lote para correr varios procesos...... 37 3.3.3- Nueva llamada al sistema en el servidor FS...... 37 3.3.4- Nueva llamada al sistema en el servidor PM ...... 39 3.3.5- Implementación de una llamada al sistema para cambiar la prioridad de un trabajo...... 41 3.3.6- Llamada al sistema obtener el tiempo de espera de un proceso determinado ...... 43

3.3.6.1- Modificación del comando ps para incluir el tiempo de espera de un proceso ...... 46 3.3.7- Implementación de una llamada al sistema para eliminar un proceso de acuerdo al mayor tiempo de CPU ...... 48 3.3.8- Documentación de las nuevas llamadas al sistema ...... 50

3.4- Planificación de procesos...... 52 3.4.1- Tipos de planificadores ...... 52 3.4.2- Algoritmos de planificación de procesos ...... 53

3.5-Los procesos en el SO MINIX 3 ...... 54 3.5.1- Planificación de procesos en SO_MINIX3 ...... 54 3.5.2- Implementación de la planificación en SO MINIX3 ...... 57 3.5.3- Modificación al algoritmo de planificación de MINIX3 ...... 59 3.5.4- Modificación al algoritmo de planificación de MINIX3 para FCFS...... 62

3.6- Resumen del capítulo ...... 63

Conclusiones ...... 64

Recomendaciones ...... 65

Referencias Bibliográficas...... 66

Índice de Figuras

Figura 1.1 Estructura del RCOS ...... 8 Figura 1.2 Estructura de MINIX 3 ...... 13 Figura 1.3 Estructura de los procesos ...... 15 Figura 2.1. Estructura de directorios del SO MINIX ...... 17 Figura 2.2 Directorio /usr/include/ ...... 18 Figura 2.3 Compilación de MINX ...... 20 Figura 2.4. Cambiar contraseña ...... 21 Figura 2.5 Agregar un nuevo usuario al sistema ...... 22 Figura 2.6 Cambiar el nombre a la máquina virtual ...... 22 Figura 2.7 Creación de mensaje para el arranque ...... 23 Figura 2.8 Edición de .profile para cambiar el prompt ...... 23 Figura 2.9 Lenguajes disponibles para el mapeo de teclado ...... 24 Figura 2.10 Mensaje inicial ...... 25 Figura 2.11 Definición de la cantidad de memoria para mined ...... 27 Figura 2.12 Modificación del tamaño de la pila para mined ...... 27 Figura 2.13 Compilación del mined ...... 28 Figura 3.1 Archivos de encabezamiento...... 30 Figura 3.2 table.c ...... 35 Figura 3.3 Creación de un lote ...... 37 Figura 3.4 Ejecución del proceso de fondo ...... 37 Figura 3.5 Código de la nueva llamada sobre FS ...... 38 Figura 3.6 Ejecución de la nueva llamada al sistema de FS ...... 38 Figura 3.7 Función do_getpids ...... 40 Figura 3.8 Función do_getpids ...... 40 Figura 3.9 Ejecución de la nueva llamada en PM ...... 41 Figura 3.10 Llamada al sistema para cambiar prioridad ...... 42 Figura 3.11 Función setprity ...... 42 Figura 3.12 Verificación de la nueva llamada en PM ...... 43 Figura 3.13 Conteo del tiempo ...... 44 Figura 3.14 Función do_wtime ...... 45 Figura 3.15 Función wtime ...... 45 Figura 3.16 Prueba de la nueva llamada ...... 46

Figura 3.17 Ejecución de ps modificado ...... 47 Figura 3.18 Función para eliminar procesos ...... 49 Figura 3.19 Prueba de la nueva llamada para eliminar procesos ...... 50 Figura 3.20 Plantilla de formato para el man...... 51 Figura 3.21 Ejecución del comando man para la nueva llamada ...... 52 Figura 3.22 Colas de procesos en MINIX 3 ...... 54 Figura 3.23 Campos de la estructura proc ...... 57 Figura 3.24 Modificación de pick_proc ...... 60 Figura 3.25 Ejecución de dos lotes de procesos ...... 61 Figura 3.26 Ejecución de nuestra modificación...... 61 Figura 3.27 Modificación realizada al archivo clock.c ...... 62 Figura 3.28 Ejecución de la modificación FCFS ...... 63

Resumen El trabajo presenta el análisis e implementación de una nueva versión del sistema operativo MINIX 3, destinado a la enseñanza de Sistemas Operativos. Se detallan las características de los sistemas operativos y se ejemplifican las herramientas que se utilizan para enseñar esa materia, particularizando en el sistema operativo MINIX 3 que es el objeto de estudio de esta investigación. La investigación que se presenta hace un estudio del código fuente de la versión 3 del MINIX y define nuevas llamadas al sistema, algoritmos de planificación, así como la documentación asociada a las páginas del manual interactivo (MAN). La nueva versión, MINIX3_UCLV, será un material de apoyo para los profesores y una guía de trabajo para los estudiantes.

Abstract The paper presents the analysis and implementation of a new version of MINIX 3 operating system, for the teaching of operating systems. Shows the characteristics of the operating systems and exemplify the tools used to teach this subject, specially focusing on the MINIX 3 operating system that is the subject of this research. The research presents a study of the source code for version 3 of MINIX and defines new system calls, scheduling algorithms, and documentation associated with interactive pages (MAN). The new version, MINIX3_UCLV will be a support material for teachers and a working guide for students.

Introducción

Antecedentes Existen actualmente muchos Sistemas Operativos (SO) que responden a los principios del movimiento de software libre, lo cual da la oportunidad de estudiar su código, pero estudiar el código interno de un SO real con todas sus funcionalidades es una tarea muy abarcadora. Por lo anterior muy pocas universidades en el mundo usan esa variante y prefieren estudiar sistemas que están hechos específicamente con fines docentes. En la facultad de Matemática, Física y Computación (MFC) se han realizado dos sistemas operativos con fines docentes, el primero SO-UCLV data de varios años y estuvo totalmente funcional para el procesador 8086/8088, el segundo pretendió ser una mejora del anterior y realmente no cumplió sus objetivos.

Planteamiento del problema El plan de estudio de la carrera Licenciatura en Ciencia de la Computación contempla el estudio de los sistemas operativos desde una perspectiva interna y con ese propósito se definen las asignaturas Sistemas Operativos I y II, dentro de sus objetivos fundamentales se pueden enumerar los siguientes (MES,2007):  Evaluar, asimilar, adaptar y crear componentes de un sistema operativo. Diseñar e instrumentar soluciones que necesitan la sincronización y comunicación entre procesos concurrentes, usando los mecanismos que ofrece el Sistema de operación.  Asimilar las principales características de diseño e instrumentación de los sistemas de archivos que se definen en cada uno de los SO objeto de estudio.  Crear programas utilizando técnicas de programación concurrente, así como asimilar los recursos brindados por los SO para su correcta utilización.  Crear habilidades para la utilización de los recursos básicos que brindan los sistemas operativos modernos.  Conocer y saber utilizar diferentes técnicas de programación a nivel de los recursos del sistema operativo en la solución de problemas de mediana complejidad. Lograr objetivos tan abarcadores y complejos en el reducido tiempo que asigna el plan de estudio es una tarea muy difícil y sin el apoyo de las herramientas adecuadas resulta imposible. 1

Introducción

Muchos textos de sistemas operativos presentan una perspectiva totalmente teórica del sistema y se refieren muy pobremente, o no se refieren, al código en sí. Esa aproximación no satisface los objetivos anteriores y por ello el colectivo de la Disciplina Sistemas de Computación, al cual están integradas las asignaturas mencionadas usa el libro Operating System Design and Implementation(Tanenbaum y Woodhull,2006), en el cual se presenta, como objeto de estudio el so MINIX1 que se hizo con objetivos docentes. La investigación que se presenta hace un estudio del código fuente de la versión 3 del MINIX y define nuevas llamadas al sistema, algoritmos de planificación, así como la documentación asociada a las páginas del manual interactivo (MAN). La nueva versión, MINIX3_UCLV, será un material de apoyo para los profesores y una guía de trabajo para los estudiantes.

Objetivos de la investigación 1. Obtener una versión modificada del SO MINIX. 2. Documentar los módulos del sistema. 3. Ofrecer una guía que permita realizar modificaciones al sistema.

Pregunta de investigación 1. ¿Permitirá una nueva versión del SO MINIX, con comentarios apropiados y funciones regidas por directivas de compilación condicional, cumplir objetivos más abarcadores a los profesores de esta disciplina?

Justificación Los sistemas operativos se estudian en todas las carreras de perfil informático con más o menos profundidad, en el caso de la carrera Ciencia de la Computación, el plan de estudio actual declara objetivos muy abarcadores y difíciles de cumplir. El sistema operativo MINIX, realizado en una universidad holandesa con el propósito específico de servir de objeto de estudio en las asignaturas relacionadas con esta temática, es una buena opción pero resulta un hecho innegable que solo se estudia superficialmente o cuando se hace más profundamente se enfoca hacia algún módulo específico. La situación anterior se complejiza aún más con la drástica reducción de horas que ha sufrido el tema en el cambio del Plan C al D.

1 Su página base en la World Wide Web puede encontrarse www.minix3.org. Tiene un grupo de noticias en USENET: http://groups.google.com/group/comp.os.minix. Introducción

Viabilidad Una de las razones que incidió negativamente sobre la segunda versión de SO-UCLV fue el hecho de no disponer de máquinas sobre las cuales se pudiera implementar el sistema en sí. Hoy en día existen diversos software que permiten emular el hardware de cualquier máquina, esos software se conocen como máquinas virtuales y la implementación del sistema se llevará a efecto sobre ellos sin necesidad de usar máquinas reales.

Hipótesis de investigación  Es posible hacer modificaciones al sistema operativo MINIX que ayuden a profesores y estudiantes en el proceso de enseñanza-aprendizaje de sus estructuras internas.  Disponer de un sistema operativo simple y ajustado a los objetivos de la asignatura homónima permite alcanzar esos objetivos en los tiempos asignados por el Plan de Estudio D.

Estructura del proyecto Este proyecto de diploma consta de tres capítulos, los cuales describen de manera diferente la aplicación a estudiar. En el capítulo I, titulado “Evolución de los sistemas operativos” se aborda las siguientes temáticas: características e historia de los sistemas operativos, se hace una análisis de las herramientas para la enseñanza de los SO, profundizando en MINIX3. El capítulo II, “Sistema operativo Minix, transformaciones sencillas”, hace un estudio del código fuente de Minix y de los elementos propios para su configuración, así como modificaciones a comandos propios del sistema. El capítulo III aborda los conceptos más difíciles de un sistema operativo: llamadas al sistema y algoritmos de planificación. En este capítulo se hace una breve y general descripción de estos conceptos y se ejemplifica cambios realizados a Minix3 reflejados en nuevas llamadas al sistema y modificaciones a los algoritmos de planificación. Capítulo I Evolución de los sistemas operativos

Capítulo I. Evolución de los sistemas operativos

1.1- Introducción En el capítulo I se presenta un estudio acerca de la evolución de los sistemas operativos. Se describen algunas de las herramientas que se utilizan para la enseñanza de sistemas operativos, detallando en las características y estructura del SO MINIX 3.

1.2-Sistema Operativo Un sistema operativo es un software de sistema, es decir, un conjunto de programas de ordenador destinado a permitir una administración eficaz de sus recursos. Comienza a trabajar cuando se enciende el computador y gestiona el hardware de la máquina desde los niveles más básicos, permitiendo también la interacción con el usuario (Tanenbaum y Woodhull,2006).

1.2.1- Breve historia del surgimiento del sistema operativo La primera computadora digital verdadera fue diseñada por el matemático Charles Babbage2. Aunque Babbage invirtió la mayor parte de su vida y su fortuna tratando de construir su máquina analítica, nunca logró que funcionara correctamente porque era totalmente mecánica. Babbage se dio cuenta que su máquina necesitaría software por lo que contrató a Ada Lovelace3 como programadora. El lenguaje de programación Ada recibió su nombre en honor a ella (Tanenbaum y Woodhull,1997). Años más tarde Tanenbaum expresó una frase que demostró con certeza la veracidad de las palabras de Babbage: "Sin su software, la computadora es un montón de metal inútil” (Tanenbaum y Woodhull,1997). La historia de los SO es una reafirmación de lo expresado anteriormente. Para trabajar con las primeras computadoras era necesario realizar un tedioso y difícil proceso de inicio que se hacía totalmente a mano y a través de paneles de control que debía manipular el operador-programador, una vez realizado el proceso inicial, era necesario cargar los programas y los datos de la misma forma. Pronto se notó que este proceso era demasiado engorroso y se escribió un módulo, denominado

2 Babbage (1792-1871) matemático ingles diseñador de la primera computadora digital. 3 Hija del famoso poeta británico Lord Byron, primera programadora de la historia. 4

Capítulo I Evolución de los sistemas operativos

monitor residente, que debía cumplir parte de esas tareas. Se puede considerar que el monitor residente constituyó el primer sistema operativo (Rodríguez et al.,2010).

Con el desarrollo de la tecnología aparecieron nuevos equipos asociados a las computadoras y, a la vez, ellas se hicieron más complejas. Se hizo necesario que el sistema operativo se encargara de controlar todos esos recursos y surgieron los sistemas de tratamiento por lotes o batch, en los cuales un grupo de trabajos se sometían, de forma no interactiva al sistema.

Los sistemas batch, aunque aún existen como parte integrante de los sistemas operativos modernos, no podían dar un buen servicio a los procesadores más veloces que fueron surgiendo y emergieron los sistemas de tiempo compartido, los cuales son muy populares hasta el presente.

En general las complejidades del hardware han precisado de más tareas a desarrollar por el sistema operativo pero han permitido que muchas de las tareas hechas por ellos hayan emigrado hacia el hardware en una historia cruzada de servicios, peticiones y migraciones de facilidades.

1.3-La enseñanza de sistemas operativos Según el Plan de Estudio D de la carrera Ciencia de la Computación, la asignatura Sistemas Operativos debe lograr que los estudiantes puedan: “…evaluar, asimilar, adaptar y crear componentes de un sistema operativo…”. Los planes de estudio anteriores (A, B, C y C mejorado) se trazaban estrategias más o menos similares, aunque en los planes A y B solo desde una perspectiva totalmente teórica y más práctica en los planes C y C mejorado debido a la necesidad de ajustarse a los recursos de cómputo de cada época para poder trabajar con el código interno del SO. El estudio del sistema operativo, en la carrera Ciencia de la Computación, puede hacerse desde cuatro perspectivas diferentes:  Totalmente teórico. Resulta inadmisible en la época actual, ya que el surgimiento y proliferación de las microcomputadoras, permite que se pueda hacer un estudio práctico de la forma interna que no permitía la época de los planes A y B, cuando no se contaba con computadora o solo había una minicomputadora disponible en toda la UCLV. 5

Capítulo I Evolución de los sistemas operativos

 Estudiar la forma de interna de un sistema operativo comercial. Esta estrategia es muy difícil debido a la complejidad que significa adentrase en las interioridades de un SO que no está hecho para ser estudiado y que es además muy grande.

 Usar alguna herramienta que simule el funcionamiento de los mecanismos internos del SO. Aunque esta manera de enfrentar el problema no es del todo mala, el problema que tiene es que no se trata de un SO real y por tanto no se puede estudiar su código y transformarlo.

 Por último puede usarse un SO hecho con fines docentes pero que tenga toda la funcionalidad de un SO comercial. Esta es la estrategia que se ha seguido en la UCLV y el SO escogido es el MINIX, que está bien documentado y que, además de distribuirse con su código fuente, ese código es profuso en comentarios útiles para el programador.

1.4-Herramientas para la enseñanza de sistemas operativos Existen, en la actualidad, muchas herramientas para la enseñanza de Sistemas Operativos. Estas herramientas están divididas en dos grupos: asistentes y sistemas operativos educativos.

1.4.1- Sistemas Operativos para la enseñanza Dentro de los sistemas operativos que se utilizan en la enseñanza se pueden señalar los siguientes: - NachOS - RCOS.java - AMOS

- RCOS - PintOS

- Xv6 - Topsy

1.4.1.1- NachOS Nachos (Not Another Completely Heuristic Operating System): es un sistema operativo educativo dirigido tanto al pregrado como al postgrado. Fue desarrollado en la Universidad de California en Berkeley por Wayne A. Christopher, Steven J. Procter y Thomas E. Anderson entre 1991 y la primavera de 1992 y se usa en numerosas escuelas (Christopher et al.,1993).

Capítulo I Evolución de los sistemas operativos

Escrito originalmente en C++ para MIPS, NachOS se ejecuta como un proceso de usuario en el sistema operativo anfitrión. Un simulador de MIPS ejecuta el código para cualquier programa de usuario que se ejecute sobre el sistema operativo NachOS. Posee 2500 líneas de código de las cuales más de mitad están dedicadas a la descripción de interfaces y comentarios.

Ha sido portado a MIPS, Sun SPARC (SunOS y Solaris), DEC Alpha, Linux, NetBSD y FreeBSD, RS/6000 y Hewlett Packard PA-RISC.

La versión 4.0 está escrita en un subconjunto de C++ ligeramente más amplio que las anteriores, utilizando plantillas para reducir las repeticiones de código. Por los comentarios de su código fuente, se terminó de desarrollar en 1996.

En 2001 Dan Hettena y Rick Cox de la Universidad de California en Berkeley portaron NachOS al lenguaje de programación Java como Nachos 5.0j, con el objetivo de hacerlo más portable y accesible para los no graduados. Es una reescritura casi total, con una estructura similar a la versión 4.0 y corrige muchos errores anteriores (Christopher et al.,1993).

1.4.1.2- RCOS

Ron Chernich’s Operating System (RCOS): Es un sistema operativo multitareas, diseñado para demostrar los principios generales de un sistema operativo mediante animación controlada. Permite hacer simples modificaciones y experimentaciones con las estructuras de datos y algoritmos, es portable y trabaja como un sistema operativo real. Se comenzó a desarrollar durante 1993 y 1994, pero no hubo resultados satisfactorios con la portabilidad por lo que en 1996 se volvió a implementar RCOS pero esta vez usando java como lenguaje de programación (Chernich et al.,2003).

Tiene una estructura de microkernel/paso de mensajes, dicha estructura se ha hecho muy popular en los sistemas operativos modernos. El kernel de RCOS4 proporciona

4 Su página en la World Wide Web se encuentra disponible en http://cq-pan.cqu.edu.au/david- jones/Projects/rcos / 7

Capítulo I Evolución de los sistemas operativos

facilidades para la comunicación con otros componentes del SO. Las restantes funcionalidades del SO se implementan en módulos separados, que responden a mensajes predefinidos del sistema. La figura 1.1 muestra la jerarquía e interacción entre los componentes de RCOS.

Figura 1.1 Estructura del RCOS

Los módulos del sistema implementado incluyen:

- una unidad de disco simple (DskModel) que acepta las características físicas como parámetros. - un sistema de archivos basado en el sistema de archivos CMP (CMPFs). - Los programas de usuarios acceden a los servicios del sistema de archivos a través de una interfaz (FsIface). - semáforos y memoria compartida (IPC). - planificación de procesos (Exec). - Manipulación de la memoria (MMUP).

El lenguaje de programación utilizado en RCOS es el Pascal Like Language Number 2(PLL/2). PLL/2 es un subconjunto de Pascal, con la diferencia de que no posee estructuras de datos complejas, solamente trabaja con enteros (Chernich et al.,2003).

RCOS se ha usado de diferentes maneras:

- Como herramienta de aprendizaje para explicar los conceptos del SO. - En la realización de ejercicios de programación donde se apliquen la concurrencia, semáforos y memoria compartida.

Capítulo I Evolución de los sistemas operativos

- En el análisis, modificación y comparación de los algoritmos y las estructuras de datos.

1.4.1.3- RCOS.java

En el año 1996 se decidió crear un nuevo RCOS usando como lenguaje de programación Java debido a que se deseaba:

- utilizar otras plataformas que no fueran MS-DOS, como por ejemplo Windows 95, NT, Linux y Macintosh. - Aumentar el uso de la www como un medio para la distribución de materiales de aprendizaje.

Además Java proporciona otros beneficios incluyendo:

- potencial para la integración de multimedia. - Mejora las funcionalidades, incluyendo soporte en la construcción para el desarrollo de interfaces visuales (GUI) y aplicaciones multi-hilos.

A partir de abril del 1996, se encuentra un prototipo funcional de RCOS.java disponible en http://euler.cqu.edu.au/rcos/.La versión actual incluye:

- Una interfaz de usuario usando las clases de GUI de Java. - Rediseño completo de la estructura del SO. - Separación de animación y ejecuciones de la CPU en hilos diferentes.

Actualmente se han integrado sólo el planificador del proceso, el kernel, términos del semáforo, pero sólo el planificador del proceso se ha representado gráficamente. El manejador de memoria con paginado, soportes de memoria compartida, el sistema de archivos CP/M y la simulación del de disco se escribieron pero no se han incorporado en la versión actual (Chernich et al.,2003).

Capítulo I Evolución de los sistemas operativos

1.4.1.5- PintOS

Pintos5 es un sistema operativo educativo derivado de Nachos, creado en la Universidad de Stanford en el 2004. Fue escrito por el estudiante graduado Ben Pfaff. Es usado en los cursos de pregrado para introducir conceptos de diseño e implementación de un sistema operativo, requiriendo la implementación de partes bastante significativas de un sistema operativo real, como son el acceso al sistema de archivos y el manejo de hilos y memoria. A diferencia de NachOS, Pintos puede ejecutarse en el hardware x86 actual, en lugar de correr como una máquina virtual sobre un sistema anfitrión y está escrito en el lenguaje de programación C en lugar de C++ (Pfaff,2004).

1.4.1.6- Topsy (Teachable Operating System)

Es un sistema operativo pequeño que se ha diseñado para la enseñanza. Fue usado activamente en los cursos de pregrados de la Ingeniería Informática II del Departamento de Tecnología de la Información e Ingeniería Eléctrica en ETH Zürich entre 1999 y 2006. Posee un microkernel multi-hilos. Fue escrito en ANSI C (Fankhauser et al.,2000).

En Topsy6 existen exactamente dos procesos: los procesos de usuario y los procesos del kernel. Topsy tiene una estructura modular. El kernel contiene tres módulos principales que reflejan las tareas básicas de un sistema operativo: dirección de memoria, control de procesos e hilos y entrada-salida. Todos los módulos del kernel son implementados como hilos. La comunicación y sincronización se lleva a cabo a través de mensajes.

1.4.1.7- AMOS

NoNameOS originalmente llamado AMOS es un sistema educativo con un plan del kernel monolítico y una implementación eficaz. Fue escrito durante los años 2005-

5 Su página en la World Wide Web se encuentra disponible en http://www.scs.stanford.edu/10wi- cs140/pintos/pintos_1.html 6 Su página en la World Wide Web se encuentra disponible en http://www.tik.ee.ethz.ch/~topsy

Capítulo I Evolución de los sistemas operativos

2006. AMOS es un sistema operativo para la arquitectura Intel x86. Posee varias funcionalidades incluidas, como por ejemplo: dirección de memoria virtual, un sistema de archivo virtual y multitarea con desalojo.

1.4.1.8- Xv6

Xv6 es un sistema operativo educativo diseñado en el verano del 2006 para el curso de Sistema operativo del MIT. Fue escrito en ANSI C. Esta concebido para correrse en multiprocesadores de Intel x86. Xv6 remplazó V67, constituyendo una mejora total ya que perfeccionó tanto el planificador como el sistema de archivos (MIT,2002).

Su código fuente es autorizado bajo la licencia del MIT. Compila usando el compilador GNU C. Puede ejecutarse en un sistema real, pero se recomienda usar el emulador Bochs.

Ha sido utilizado en los cursos de sistemas operativos en diversas universidades como por ejemplo: Rutgers, Yale, Johns Hopkins y Tsinghua.

1.4.2- Asistentes para la enseñanza de sistemas operativos Con el objetivo de mejorar la enseñanza en los cursos de sistemas operativos, se han creado diversas herramientas y asistentes. Existen asistentes que son extensiones de otros sistemas operativos como por ejemplo DYNAMIX.

1.4.2.1- DYNAMIX

DYNAMIX es una herramienta que despliega el interior de un sistema operativo y demuestra la interacción entre sus componentes funcionales. Se dio a conocer, en una disertación hecha Grabczewski supervisado por Liu. Se ha usado para ayudar en la enseñanza de conceptos de sistemas operativos en la Universidad Birkbeck (Grabczewski y Liu,1993). Está escrito en el lenguaje programación C (Grabczewski y Liu,1993).

7 Sistema operativo educativo obsoleto, escrito en un lenguaje obsoleto conocido como pre-K&R C y con hardware desfasado (PDP -11). 11

Capítulo I Evolución de los sistemas operativos

DYNAMIX (dynamic-MINIX) es una extensión del kernel de MINIX. Despliega una ventana dinámica dentro del sistema operativo MINIX, permitiéndole al usuario ver literalmente los componentes principales y como interactúan entre ellos.

El diseño de MINIX se basa en usar los procesos de cliente servidor dentro del propio kernel, posibilitando la comunicación de los procesos en el kernel pasando mensajes. DYNAMIX trabaja interceptando cualquier mensaje e interrupción.

1.5- Características del sistema operativo MINIX 3 MINIX 3 fue públicamente anunciado el 24 de octubre de 2005 por Andrew Tanenbaum, durante su exposición en la conferencia de ACM8 en el Symposium on Operating System Principles (Tanenbaum y Woodhull,2006). Es un sistema operativo de código abierto diseñado para ser altamente confiable, flexible y seguro, se basa en las versiones anteriores del MINIX, pero es fundamentalmente diferente en muchas maneras. MINIX 1 y 2 fueron concebidas como herramientas de enseñanza; MINIX 3 añade el nuevo objetivo de ser utilizada como un sistema real para usarse en computadoras con recursos limitados y embebidos y para aplicaciones que requieren alta fiabilidad. Referente a lo anterior, Tanenbaum expresó: Esté por favor enterado que MINIX 3 no es MINIX de su abuelo… MINIX 1 fue escrito como herramienta educativa…. MINIX 3 es eso, mas el comienzo de la construcción de un sistema operativo altamente confiable y libre… MINIX 1 y MINIX 3 son relacionados de la misma forma que son Windows 3.1 y Windows XP: el mismo nombre (Tanenbaum,2006). MINIX 3, se basa en el estándar de POSIX y se publica bajo de Licencia del DEB y puede descargarse libremente de www.minix3.org. MINIX 3. Soporta sólo arquitecturas derivadas de IA-32, y está disponible en LiveCD, lo que permite ser utilizado sin necesidad de instalar el sistema operativo, y en versiones compatibles con sistemas de emulación o virtualización como BOCHS, Qemu, VMware y VirtualPC. Cuenta con redes TCP / IP y es compatible con el sistema de ventanas X. Ejecuta las herramientas del compilador GNU y de muchos otros sistemas Unix. Posee un alto grado de tolerancia a fallos (Llorente et al.,2002, Tag,2011).

8 Asociación de científicos de la computación. 12

Capítulo I Evolución de los sistemas operativos

Este nuevo sistema operativo es muy pequeño, se ejecuta en modo kernel en 6000 líneas de código ejecutable. Las piezas que se ejecutan en modo de usuario se dividen en pequeños módulos, bien aislados unos de otros. Estas características, la pequeña cantidad de código del kernel, y otros aspectos refuerzan el sistema de fiabilidad (Tag,2011).

1.5.1- Estructura de MINIX 3 MINIX 3 tiene una estructura de microkernel dividida en 4 capas como se muestra en la figura 1.2

Figura 1.2 Estructura de MINIX 3

Cada capa contiene una función en específico, como por ejemplo: 1. La capa 1, interactúa directamente con el hardware. Es la encargada de atrapar todas las interrupciones y trampas, de planificar y ofrecer a las capas superiores un modelo de procesos independientes y secuenciales para comunicarse mediante el uso de mensajes. En resumen cuenta con dos partes bien definidas: la primera trata todo lo referente a la programación de bajo nivel para brindar la abstracción de procesos a las capas superiores. La segunda parte gestiona los aspectos más mecánicos de los mensajes, como lo son los buffers de envío y recepción de mensajes que se alojan en la memoria física, las verificaciones de destinos y todo lo referente al manejo físico de memoria en lo que respecta a los mensajes. La primera capa es la que está escrita en lenguaje ensamblador. El resto de las capas ya está escrito en lenguaje C (Tanenbaum y Woodhull,2006, Tejo,2011).

Capítulo I Evolución de los sistemas operativos

2. La capa 2, contiene todo lo concerniente a los procesos de E/S, uno por cada tipo de dispositivos (tareas). Existen tareas para discos, impresoras, relojes, interfaces de red y tareas de sistema, que si bien no son dispositivos de sistema sí tienen por finalidad el servicio de copiado entre diferentes regiones de memoria para procesos que no cuentan con los privilegios para realizarlos ellos mismos. Todas las tareas de la capa 2 y el código de la capa 1 se combinan para formar un solo programa binario llamado kernel, aunque a pesar de que son compilados juntos cuando el kernel y los manejadores de interrupciones se están ejecutando estos tienen mayores privilegios que las tareas. De este modo se logra que el kernel pueda ejecutar todo tipo de instrucciones usando datos de cualquier parte del sistema, a fin de poder acceder a cualquier parte de la memoria y cualquier registro de procesador. Sin embargo, las tareas a pesar de no contar con los privilegios a nivel de kernel sí pueden acceder a cualquier región de memoria que pertenezca a un proceso menos privilegiado con el objetivo de realizar E/S para ellos (Tanenbaum y Woodhull,2006, Tejo,2011).

3. La capa 3 aglutina los procesos conocidos como procesos servidores. Se ejecutan en un nivel menos privilegiado que el kernel o las tareas y no acceden directamente a los puertos de E/S. Tampoco pueden acceder a otra región de memoria que no sea la que le fue asignada. Hay dos servidores esenciales: el process manager (PM) y el file system (FS). El PM lleva adelante las llamadas al sistema de MINIX 3 que involucran el arranque y detención de procesos, tales como fork, exec y exit, y las llamadas relacionadas con las señales, como alarm y kill, que pueden alterar el estado de los procesos. El process manager también es responsable de gestionar la memoria con la llamada al sistema brk. El file system (FS) se ocupa de todas las llamadas al sistema de archivos, como read, mount y chdir. Además del PM y el FS hay otros servidores en la capa 3. El information server (IS) proporciona información de estado y de depuración sobre los otros drivers y servers. El reincarnation server (RS) inicia y si es necesario reinicia, los controladores de dispositivos (drivers) que no se cargan en memoria junto con el kernel. En un sistema que está en red, se levanta un servidor adicional:

Capítulo I Evolución de los sistemas operativos

el network server (inet), también en capa 3. Los servidores no pueden hacer E/S directamente pero pueden comunicarse con los drivers para solicitar la E/S (Tanenbaum y Woodhull,2006, Tejo,2011). 4. En la capa 4 finalmente se alojan todos los procesos de usuario tales como shells, editores, compiladores, programas, etc. (Tanenbaum y Woodhull,2006, Tejo,2011).

La gestión de procesos tiene lugar según tres niveles de prioridad: las tareas de E/S, servidores y procesos de usuario. Dentro del núcleo sólo queda la gestión de la comunicación entre tareas, la planificación, la gestión de interrupciones, y, por supuesto, todo lo referido al arranque y detención del sistema (Llorente et al.,2002). La figura 1.3 muestra esta estructura.

Figura 1.3 Estructura de los procesos

1.5.2- Aplicaciones de MINIX3 Debido a sus características, Minix3 tiene varias aplicaciones en la actualidad en las siguientes áreas (Tag,2011): 1. Aplicaciones donde se requiere una fiabilidad muy alta.

2. Se utiliza en computadoras de un solo chip, pequeña-RAM, de bajo consumo, como por ejemplo computadoras portátiles para los niños del Tercer Mundo.

3. En sistemas integrados (por ejemplo, cámaras fotográficas, discos de DVD, teléfonos celulares).

Capítulo I Evolución de los sistemas operativos

4. Aplicaciones en las que la GPL es demasiado restrictiva (MINIX 3 utiliza un tipo de licencia BSD).

5. Educación (por ejemplo, cursos de sistemas operativos en las universidades). Como es el caso de la UCLV en donde se estudia el SO y se transforma su forma interna.

1.6- Resumen El capítulo I ha presentado, de forma muy general, una breve historia de los SO y una descripción de algunas de las herramientas que se usan para la enseñanza de este importante componente de cualquier sistema de cómputo. Se ha hecho énfasis en el SO MINIX que es el objeto de estudio de este trabajo de investigación. En el próximo capítulo se describen las transformaciones hechas al SO MINIX 3, las cuales servirán de apoyo a los cursos de SO de la UCLV y quizás de otras universidades.

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

Capítulo II. Sistema operativo MINIX, transformaciones sencillas

2.1- Introducción El capítulo II, estudia el código fuente del sistema operativo MINIX 3 y presenta pequeñas modificaciones que se relacionan con la configuración inicial del SO. El capítulo servirá de material de apoyo a los estudiantes para realizar esas tareas, entre las que se pueden enunciar: adicionar un nuevo usuario, generar una contraseña y personalizar algunos aspectos del arranque del sistema.

2.2- Organización del código fuente del SO MINIX 3

La estructura de directorio del SO MINIX tiene la organización clásica de los SO de la familia UNIX (figura 2.1). El código fuente del sistema se localiza en la ruta absoluta /usr/src.

Figura 2.1. Estructura de directorios del SO MINIX

Cada uno de los subdirectorios contenidos en /usr/src contiene un archivo denominado Makefile que lo utiliza el comando make para gestionar la compilación eficiente de los programas que constan de múltiples archivos fuentes.

El directorio /usr/src puede ser relocalizado pues los archivos Makefile, de cada directorio de fuentes, usan una ruta relativa para cada directorio de fuentes en C. 17

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

Cada archivo Makefile espera encontrar los encabezamientos en /usr/include, sin embargo, /usr/src/tools/Makefile espera los encabezamientos en /usr/src/include (borra /usr/include y lo rellena con /usr/src/include). Esto se hizo así para mantener, en un solo lugar, todos los archivos necesarios para el desarrollo de MINIX 3.

Los archivos fuentes en C, pueden referenciar los archivos de encabezado de varias maneras y de acuerdo a la convención del compilador del lenguaje C que es el usado para el desarrollo del SO MINIX (excepto pequeños fragmentos en ensamblador):

 #include Se espera que nombre1.h esté en el directorio de cabecera predeterminado, el cual es casi siempre /usr/include/  #include "nombre2.h" busca a nombre2.h en el directorio local donde se realiza la compilación.

El directorio /usr/include/ contiene una cierta cantidad de archivos de cabecera POSIX estándar y además tiene los tres directorios que muestra la figura 2.2.

Figura 2.2 Directorio /usr/include/

A los fines de permitir extensiones a MINIX 3 y programas que corren en el entorno de MINIX 3, hay otros archivos y subdirectorios en /usr/include/ .Por ejemplo include/arpa/, include/net/ y su subdirectorio include/net/gen/ que permiten extensiones de red.

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

El directorio /usr/src/ contiene otros tres importantes subdirectorios con código fuente del SO:

 kernel/ capa 1 (planificación, mensajes, tarea del reloj y tarea del sistema) Incluye las funciones que gestionan la inicialización del sistema, las interrupciones, el paso de mensajes y la planificación de procesos. La tarea del sistema hace de interfaz entre los servicios del kernel y los procesos de las capas superiores. La tarea del reloj proporciona servicios de temporización al kernel. Ambas tareas están compiladas en el mismo binario del kernel, pero corren como procesos separados.  drivers/ capa 2 (device drivers para disco, consola, impresora, etc.)  servers/ capa 3 (PM, FS, otros servers) o servers/pm/ process manager server o servers/fs/ file system server

Hay otros directorios de código fuente en /usr/src/ como:

 lib/ código fuente para los procedimientos de biblioteca (ej.: open, read, etc.)  tools/ el Makefile y los scripts para armar el sistema MINIX 3.  boot/ el código para arrancar e instalar un sistema MINIX 3.  servers/: init y rs  inet/ código fuente del servidor de red.  drivers/ fuentes de los controladores de dispositivos: drivers de discos alternativos, tarjetas de sonido y adaptadores de red.

Como MINIX 3 es un sistema operativo experimental, concebido para ser modificado, hay un directorio /usr/src/test/ con programas diseñados para verificar completamente alguna nueva versión del sistema MINIX 3 recién compilado.

El SO sirve para darle soporte a los comandos (commands) que van a correr sobre él. En consecuencia hay un directorio /usr/src/commands/ con los fuentes de los programas utilitarios típicos de los sistemas de la familia UNIX, tales como: cat, cp, date, ls, pwd, etc.

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

2.3- Proceso de compilación del sistema operativo Para compilar MINIX3, es necesario situarse en el directorio /usr/src/tools/ y ejecutar make. Una vez ejecutado make aparecen todas las opciones disponibles para compilar MINIX 3 como se muestra en la figura 2.3.

Figura 2.3 Compilación de MINX Por ejemplo para compilar la imagen del sistema es necesario estar en /usr/src/tools y ejecutar el comando make image. La acción anterior realiza las acciones siguientes:  Hace una copia fresca desde /usr/src/include en /usr/include. Se compilan los fuentes en los directorios /usr/src/kernel, /usr/src/servers/ y /usr/src/drivers. Todos los objetos del kernel se enlazan para formar un solo programa ejecutable: el kernel.  Los objetos de /usr/src/servers/pm/ se enlazan para crear el programa pm y los de /usr/src/servers/fs/ se enlazan para crear a fs. También se crean: rs (y service), init, los drivers: tty, memory, at_wini, floppy, bios_wini y log.

Los otros drivers, incluso los de red, no hacen falta para compilar un sistema MINIX 3 básico.

Luego, para crear un archivo que se pueda cargar desde los bloques de disco, el programa installboot (cuyas fuentes están en /usr/src/boot) corre y concatena los

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

componentes de la imagen del sistema (kernel, pm, fs, init y los demás). Esta nueva imagen, denominada image se crea en /usr/src/tools/image.

La imagen se puede copiar al directorio /usr/src/boot o /usr/src/boot/image/ de un disquete o una partición del disco rígido. Será tarea del boot monitor la carga de esa imagen y transferirle el control al SO.

MINIX 3 consta de varios programas independientes que se comunican sólo mediante el paso de mensajes. Si hay un procedimiento con el mismo nombre en dos de esos programas, no hay ningún conflicto porque se enlazan en ejecutables diferentes. Algunas rutinas de /usr/src/lib/ son comunes a las tres partes del SO.

Además, como los drivers son programas independientes del núcleo, se pueden agregar un driver Ethernet y el server init después de cargar la imagen. Esos procesos se arrancan desde /usr/etc/rc y se cargan en las regiones de memoria disponibles para programas de usuarios.

2.4- Configuración del SO MINIX 3 Una vez instalado el sistema operativo MINIX3 debe realizarse el proceso de configuración del sistema, la cual será propia e individual para cada usuario, entre las posibilidades se pueden enumerar las siguientes: adicionar un nuevo usuario, definir una contraseña, crear mensajes para lanzarlos en el inicio del sistema y configurar el teclado.

2.4.1- Configuración de un password para el usuario root Una vez instalado Minix, se puede definir una contraseña para root, lo primero que se debe hacer es entrar como root y luego usar el comando passwd, como se muestra en la figura 2.4 (Snatverk,2009).

Figura 2.4. Cambiar contraseña

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

2.4.2- Adicionar un nuevo usuario al sistema Una vez creado un password para el root, se puede adicionar un nuevo usuario al sistema. Para ello se usa el comando adduser, por ejemplo: adduser guest other /home/guest, Lo anterior significa que se va a adicionar un nuevo usuario de nombre guest, su directorio (home) está en /home/guest y su forma de trabajo (permisos que posee) es la de cualquier usuario (other) (Snatverk,2009). El procedimiento anterior se muestra detalladamente en la figura 2.5.

Figura 2.5 Agregar un nuevo usuario al sistema

2.4.3- Cambiar de nombre a la máquina virtual

En las prácticas de sistemas operativos se usan máquinas virtuales para poder hacer todos los cambios sin afectar la disponibilidad de máquinas reales.

Para cambiar el nombre de la máquina virtual debe editarse el archivo /etc/hostname.file con el editor de texto mined, según muestra la figura 2.6, este cambio es temporal y deberá hacerse cada vez que se apague la máquina (Brito,2007).

Figura 2.6 Cambiar el nombre a la máquina virtual 22

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

2.4.4- Mensaje de bienvenida al iniciar el SO El mensaje de bienvenida que presenta el SO al iniciarse, está contenido en el archivo de configuración /etc/issue (Brito,2007). En esta versión del SO no se encuentra el archivo issue, sin embargo en etc/rc se localiza el siguiente alias:

Esto significa que si la variable action es verdadera, entonces se muestra el contenido del archivo issue. La figura 2.7 muestra el proceso con el mensaje “Welcome to SO MINIX 3 Version UCLV”

Figura 2.7 Creación de mensaje para el arranque

2.4.5- El promt del usuario root El shell del SO lanza un símbolo a la terminal cuando se inicia y cada vez que termina una tarea para indicar que está listo, por defecto el símbolo en los SO de la familia UNIX es # y está contenido en el archivo shell script denominado .profile, la figura 2.8, muestra el proceso de edición.

Figura 2.8 Edición de .profile para cambiar el prompt 23

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

2.4.6- Configuración del idioma del teclado Existen dos formas de configurar el teclado según el idioma deseado: 1. La primera consiste en cargar un mapeo de un idioma determinado usando el comando loadkeys, para lo cual se escoge algunos de los lenguajes que proporciona el SO (figura 2.9). Seguidamente se muestra, como ejemplo, el mapeo del lenguaje español (Brito,2007). loadkeys /usr/lib/keymaps/spanish.map Con lo anterior se carga el mapeo en memoria, pero la próxima vez que se reinicie el sistema, se debe hacer nuevamente el procedimiento.

Figura 2.9 Lenguajes disponibles para el mapeo de teclado 2. La otra forma evita tener que hacer la operación anterior cada vez que se necesita, para lo cual se configura para que se haga en el proceso de inicio del sistema, copiando el mapeo elegido al archivo de inicialización /etc/keymap, ejemplo (Brito,2007): cp /usr/lib/keymaps/spanish.map /etc/keymap

2.4.7- Mensaje inicial para reflejar nuevos cambios en el SO MINIX 3 Cuando se trabaja con una nueva versión del SO, el estudiante debe hacer modificaciones en los diferentes módulos. Cada estudiante crea una máquina propia e individual que transcurre por diferentes versiones que se obtienen en un proceso progresivo que va, desde las modificaciones más simples, como las que se han presentado hasta el momento, hasta las complejas que se verán en el capítulo 3. Para identificar las principales diferencias que existen con cada una de las versiones resulta útil que se presente un mensaje en el proceso de carga del sistema, que permita conocer cuál versión de sus modificaciones es la que se está cargando. El mensaje de la versión original se encuentra en los archivos /etc/motd y /etc/motd.install.

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

La figura 2.10 muestra un mensaje nuevo que se lanza en el proceso de arranque, una vez que se han modificado los archivos mencionados.

Figura 2.10 Mensaje inicial

2.4.8- Mensaje durante el arranque del sistema El mensaje de arranque del sistema está integrado a la función announce que se encuentra en /usr/src/kernel/main.c la cual usa la sentencia kprintf para imprimir el mensaje (Infórmatica,2010/2011). Para cambiarlo deberá editarse el archivo mencionado y poner el mensaje deseado, ejemplo:

kprintf("Bienvenidos al sistema operativo MINIX3\n");

En este caso la modificación no se ha hecho en unos de los archivos script del SO, los cuales se exploran en el arranque para interpretar las acciones contenidas en ellos, sino que se ha modificado uno de los fuentes del SO, por ello que será necesario compilar e instalar la nueva imagen del SO. El procedimiento general para estos casos es el siguiente: 1. Modificar el archivo fuente. 2. Cambiarse al directorio /usr/src/tools 3. Ejecutar make install para que se compile el sistema y se instale la nueva imagen.

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

2.5- Modificaciones al editor mined Uno de los editores que se instala con el SO MINIX, es el mined, es un buen editor para trabajar desde una terminal, pero tiene la limitación de que no permite editar archivos grandes, tales como table.c, trace.c, system.c, etc. Existe, además del editor mined, el elvis instalado en la versión 3.1.2a de MINIX 3. Para modificar archivos no muy grandes se utiliza el mined por ser fácil de usar, todo lo contrario del elvis que es la versión del editor vi que usa el MINIX. Para los cursos de SO, resulta más conveniente usar el mined, ya que la materia tiene muchas complejidades y aprender un editor como el elvis significa hacer más complejo el proceso de enseñanza-aprendizaje sin una necesidad justificada. Seguidamente se presenta, en forma de pasos, la modificación hecha al mined para extender su capacidad de carga y edición. 1. Situarse en el directorio /usr/src/commands/mined 2. Editar el archivo mined.h y buscar el fragmento siguiente: If(CHIP == INTEL) #define MEMORY_SIZE (50 * 1024) /* Size of data space to malloc */ #endif

3. La constante MEMORY_SIZE, define un espacio de memoria que será reservado por una posterior sentencia malloc, se aumenta el espacio a reservar, como se muestra seguidamente, debe tenerse cuidado de no reservar demasiada memoria tomando en cuenta la memoria física que dispone la máquina anfitriona sobre la que corre la máquina virtual, en este caso se ha ajustado a 300 * 1024, como se muestra en el código siguiente y en la figura 2.11. If (CHIP == INTEL) #define MEMORY_SIZE (300 * 1024) /* Size of data space to malloc */ #endif

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

Figura 2.11 Definición de la cantidad de memoria para mined

4. Ahora es necesario ajustar el archivo Makefile a las nuevas necesidades, para lo cual debe buscarse, dentro de él, el fragmento siguiente: mined: $(OBJ) $(CC) – i – o $@ $(OBJ) Install –S 64k $@ Cambiar 64 por 512, como se muestra a continuación mined: $(OBJ) $(CC) – i – o $@ $(OBJ) Install –S 512k $@ El fragmento anterior especifica que el programa mined tendrá 512Kb de memoria para el stack. En minix, la suma del crecimiento del stack y los datos los datos no puede sobrepasar el tamaño del stack, la figura 2.12 muestra el cambio.

Figura 2.12 Modificación del tamaño de la pila para mined

Capítulo II Sistema Operativo MINIX, transformaciones sencillas.

5. Por último se compila el nuevo mined ejecutando el siguiente comando desde el mismo directorio (la figura 2.13 muestra el proceso): make install

Figura 2.13 Compilación del mined

2.6- Resumen del capítulo En el capítulo se ha hecho un análisis del código fuente del sistema operativo MINIX 3. Basado en ese análisis se hicieron modificaciones a la configuración del sistema y a algunos comandos simples.

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Capítulo III. Arquitectura del MINIX. Transformaciones a sus componentes

3.1- Introducción En este capítulo se realiza una investigación de los principales conceptos de los sistemas operativos: planificación de procesos y llamadas al sistema. Estos conceptos serán aplicados al sistema operativo MINIX 3, donde se presentará como se implementan llamadas al sistema en los módulos FS y PM, así como las modificaciones a los algoritmos de planificación.

3.2- Archivos de encabezamiento comunes en MINIX 3 Antes de comenzar con las implementaciones de una nueva llamada al sistema, el estudiante deberá conocer cada uno de los archivos de encabezamiento y las estructuras que se utilizan en MINIX 3, así como sus funciones generales, por eso seguidamente se realiza una breve descripción de cada uno de ellos (Tanenbaum y Woodhull,2006).

El directorio /usr/include/ y sus subdirectorios contienen una colección de archivos que definen constantes, macros y tipos. El estándar POSIX requiere muchas de esas definiciones y especifica cual archivo deberá estar dentro del directorio principal /usr/include/ o en el subdirectorio /usr/include/sys/.

Los archivos dentro de esos directorios se llaman de cabecera o encabezado (header files) y tienen extensión .h. Se incluyen mediante la sentencia #include en los fuentes C.

Los encabezados que hacen falta para compilar programas de usuario se encuentran principalmente en include/. Para compilar programas y utilidades del sistema se usan encabezados que están en include/sys/. La distinción no es tan importante. En la compilación de un programa de usuario se pueden usar archivos pertenecientes a ambos (Tanenbaum y Woodhull,2006).

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

En la figura 3.1 se muestran los archivos de encabezamiento más comunes en MINIX3.

Figura 3.1 Archivos de encabezamiento Seguidamente se describen los archivos de encabezamiento comunes:  minix/config.h establece parámetros para “kernel”, “pm” y “fs”.  ansi.h determina si el compilador utilizado cumple los requerimientos de C estándar. Define la macro _PROTOTYPE para compiladores ANSI y K&R.  limits.h define varios tamaños básicos (cantidad de bits en un entero, límites del sistema operativo, etc.)  errno.h contiene los códigos de error que se devuelven a los programas de usuario, cuando falla una llamada al sistema (códigos positivos), en la variable global errno,. También se utiliza para identificar algunos errores internos (códigos negativos). Se distingue de error interno o de usuario según la macro _SYSTEM.  sys/types.h define tipos de datos para usar dentro de MINIX.  unistd.h define constantes y prototipos generalmente relacionados con POSIX.  string.h define prototipos relacionados con el manejo de string.  signal.h define los nombres estándares de señales y algunos prototipos relacionados con ellas. A continuación se presentan los archivos de encabezamiento de MINIX:  Los archivos include/minix son necesarios para construir MINIX sobre cualquier plataforma. Según haya diferencias puntuales en el hardware o

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

según sea la forma en que se desee utilizar MINIX, puede ser necesario modificar minix/config.h o minix/sys_config.h (que es incluido por el anterior).  minix/type.h introduce algunas estructuras importantes como son: o La estructura sigmsg permite indicar al kernel, cuando se activa una señal, que la siguiente vez que planifique al proceso arranque el manejador de la señal. o La estructura kinfo permite indicar la ubicación del kernel a otras partes del sistema. PM la utiliza para actualizar la tabla de procesos.  minix/ipc.h contiene la estructura message así como las definiciones de los tipos de mensajes y los prototipos de las funciones que permiten operar con los mismos.  minix/syslib.h contiene prototipos para permitir que algunos componentes del sistema operativo puedan acceder a los servicios de otros componentes.  minix/callnr.h contiene los códigos que deben enviarse en los mensajes cuando un proceso de usuario invoca una llamada al sistema.  minix/com.h suministra definiciones comunes para la comunicación entre servidores y manejadores de dispositivos.  minix/devio.h define tipos y constantes para facilitar el acceso a puertos de entrada-salida a procesos de usuario. Los archivos de encabezamiento que utilizan estructuras de datos son:  kernel/config.h permite indicar qué llamadas al sistema se incluyen en el código del núcleo y cuáles no.  kernel/const.h suministra algunas macros para convertir de direcciones virtuales a direcciones relativas a la base del núcleo, para realizar operaciones con mapas de bits, así como se declaran las constantes que permiten establecer los privilegios para acceder al sistema de interrupciones y puertos de entrada-salida.  kernel/type.h contiene, entre otras cosas, la estructura que describe como se salvan los registros del procesador en la pila (stackframe_s), así como la estructura que permite aprovechar los mecanismos de protección de espacios

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

de los procesadores Intel 386 y posteriores, de forma que un proceso no acceda fuera de las zonas que tiene permitidas (segdesc_s).  kernel/proto.h define prototipos de funciones que deben conocerse fuera del archivo en el que se definen, muchas de las cuales son dependientes del sistema.  kernel/glo.h cumple el mismo cometido que el indicado con minix/glo.h. Destaca la variable aout en la que el monitor de arranque (“boot monitor”) introduce información al núcleo de los procesos en la imagen de arranque.  proc.h Se encuentra la estructura proc, donde se definen y describen los diferentes valores que puede adquirir el campo p_rts_flags (motivos por los que un proceso no es panificable). También se especifican la cantidad de colas para planificación y valores posibles para el campo p_priority según se trate de una tarea, proceso de usuario o proceso ocioso. Por último se definen una serie de macros que permiten un acceso más eficiente a la tabla de procesos.  table.c no contiene código ejecutable, pero el archivo objeto que se genera al compilarlo (table.o) contiene todas las estructuras de datos del núcleo. La mayoría de dichos datos se encuentran en glo.h donde se redefine EXTERN como string nulo para conseguir la correcta asignación de memoria para dichas variables. Se definen también constantes que determinan a quién se pueden enviar mensajes y notificaciones.

3.3- Las llamadas al sistema

Llamada al sistema o System Call es el mecanismo usado por una aplicación para solicitar un servicio al sistema operativo. Las llamadas al sistema son la forma en las que las aplicaciones interactúan con el sistema operativo, se puede decir que es el interface entre los programas y el SO (Mikelats,2009 ).

Las llamadas al sistema proporcionan, a los usuarios, una forma de acceder a los recursos y servicios del sistema operativo. Ellas permiten que el acceso a los recursos y dispositivos se haga de forma segura y controlada por el sistema operativo, así se evita un abuso y mal uso de los mismos (Silberschatz et al.,2005).

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

La mayor parte de las llamadas al sistema en MINIX cumplen con el estándar POSIX, el cual establece una interfaz mínima de llamadas al sistema que los sistemas operativos deben cumplir para que sean compatibles con UNIX.

Cada sistema operativo implementa un conjunto propio de llamadas al sistema, MINIX3 tiene principalmente 53 llamadas al sistema y algunas otras que son muy especiales.

Cuando se invoca una llamada al sistema, la ejecución del programa que la invoca se interrumpe y sus datos se guardan en su PCB9, para poder continuar ejecutándose luego. El procesador entonces comienza a ejecutar las instrucciones de código de alto nivel de privilegio, para realizar la tarea requerida. Cuando esta finaliza, se retorna al proceso original, y continúa su ejecución. El retorno al proceso demandante no obligatoriamente es inmediato, depende del tiempo de ejecución de la llamada al sistema y del algoritmo de planificación de la CPU.

La implementación de las llamadas al sistema requiere un control de transferencia que involucra características específicas de la arquitectura del procesador. Una forma típica de implementar es usar una interrupción por software.

MINIX 3 tiene una arquitectura de microkernel. Este microkernel se ocupa de interrupciones, proporciona los mecanismos básicos para la dirección del proceso, permite la intercomunicación entre procesos y realiza la planificación del proceso. Los sistemas de archivos, la dirección de procesos, los servicios de redes y otros están disponibles en los diferentes módulos del microkernel. Las llamadas al sistema manejadas por los servicios son ahora procesadas fuera del kernel. El kernel soporta unas pocas llamadas al sistema y estas son llamadas sistemas de tareas (Jayaraman,2006, Meurs,2006). El SO MINIX 3, se basa en diferentes módulos que se denomina servidores, existen dos servidores importantes el FS (File System) y el PM (Process Manager). El FS se encarga del manejo de archivos (creación, borrado, etc.) y el PM se encarga de todo lo referente a los procesos del sistema (Tanenbaum y Woodhull,1997).

9 Bloque de Control de Proceso: estructura de datos que controla los recursos y estado de un proceso. 33

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Cuando un proceso de usuario necesita ejecutar una llamada al sistema, lo hace enviándole un mensaje a uno de los servidores (MP o FS), indicándole la llamada que desea hacer, el servidor realiza lo necesario para cumplir la petición y si hiciera falta acceder a un dispositivo o a la memoria global del núcleo, el servidor entonces le envía un mensaje a la tarea indicada. Esto es posible debido a que el MINIX es un sistema estructurado por capas, donde cada una se comunica con sus capas adyacentes a través de mensajes (Caballero,2006).

3.3.1- Adición de una nueva llamada al sistema Para agregar una nueva llamada al sistema se escribe el manejador de la llamada y su biblioteca. El manejador de una llamada al sistema es una función que se invoca en respuesta a una solicitud del usuario, cada llamada al sistema tiene un manejador. Una biblioteca de usuario empaqueta los parámetros para la llamada al sistema y llama al manejador en el servidor apropiado. Los usuarios siempre invocan la llamada al sistema usando una biblioteca. Es importante escoger el servidor correcto para la llamada al sistema. Por ejemplo, si la llamada debe actualizar el FS (File System) o la estructura de datos fproc, entonces el manejador deberá ponerse en el servidor FS (Jayaraman,2006). El código fuente de todos los servidores se encuentran en /usr/src/servers. Cada servidor tiene un directorio separado donde residen dos archivos fuentes importantes: table.c y proto.h. Table.c contiene la definición de call_vec. Call_vec que es un puntero de arreglo de funciones el cual es indexado por el número de la llamada al sistema. Cada línea asigna una única entrada en la tabla de procesos y el índice de la entrada es el número de la llamada al sistema (Jayaraman,2006). Seguidamente se presentan los pasos para crear una nueva llamada al sistema: 1. Crear el manejador de la llamada al sistema. Para crear el manejador de la llamada hay que situarse en el directorio /usr/src/servers/, y después elegir en cuál servidor será implementada la llamada. Por ejemplo si se elige FS, entonces se debe modificar /usr/src/servers/fs/table.c.

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

La figura 3.2 contiene unas entradas de /usr/src/servers/fs/table.c, la segunda línea en la tabla asigna la dirección de la función do_exit ().El índice de la segunda entrada, es el número de la llamada al sistema para llamar al manejador do_exit ().

Figura 3.2 table.c Para adicionar una nueva llamada al sistema, es necesario identificar una entrada sin uso y definir lo siguiente: do_system_name, /* #_free = system_name */ 2. En el segundo paso se declara el prototipo del manejador de la llamada al sistema en el archivo /usr/src/servers/fs/proto.h. El archivo proto.h define los prototipos de todas las funciones de los manejadores de las llamadas al sistema. Dicho prototipo se define de la siguiente manera: _PROTOTYPE (int do_system_name, (void)); 3. Definir la función del manejador de la llamada. Los archivos misc.c, stardir.c, write.c y read.c que se encuentran en /usr/src/servers/fs y misc.c, getset.c, signal.c y time.c de /usr/src/servers/pm contienen las definiciones para las funciones de los manejadores de las llamadas al sistema. Se puede agregar el manejador de la llamada al sistema en uno de estos archivos o tenerlo en un archivo separado. Si se escoge agregarlo en un archivo separado, hay que hacer los cambios en el usr/src/servers/fs/Makefile. 4. Compilar el servidor escogido. Para compilar el servidor se realizan los siguientes pasos: 1. Ir al directorio /usr/src/servers/ 2. Ejecutar el comando “make image” 3. Ejecutar el comando “make install”

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

5. Crear una función de biblioteca de usuario. Una función de biblioteca empaqueta los parámetros para el manejador de la llamada al sistema en la estructura del mensaje y llama a la función del manejador. Primeramente se usa #define para mapear el número del manejador de la llamada al sistema y tener un identificador en el archivo /usr/src/include/minix/callnr.h y en /usr/include/minix/callnr.h de la siguiente manera: #define SYSTEM_NAME #_free Seguidamente se crea la función de biblioteca de usuario para la llamada al sistema do_system_name () en el archivo _system_name.c el cual deberá ubicarse en el directorio /usr/src/lib/posix/. 6. Compilar la nueva biblioteca. Para compilar la biblioteca se realizan los pasos siguientes: 1. Ir al directorio /usr/src/lib/posix/. 2. Agregar el nombre del archivo _system_name.c /usr/src/lib/posix/Makefile.in y en usr/src/lib/posix/Makefile. 3. Ejecutar el comando “make Makefile”, generando un nuevo makefile con las reglas del nuevo archivo incluidas. 4. Ir al directorio /usr/src/. 5. Ejecutar el comando “make libraries”. 7. Actualizar los servidores y crear una nueva imagen para el inicio. Esta imagen se creará en el directorio /boot/image y para hacer la imagen del boot se deben realizar los pasos siguientes: 1. Ir al directorio /usr/src/tools. 2. Ejecutar el comando “make hdboot” o “make fdboot” según el servidor escogido. 3. Ejecutar el comando “make install” Después de hacer los cambios anteriores debe comprobarse el trabajo realizado para lo cual se debe crear, en el directorio /home/test, un archivo *.c, donde se llamará a la función del manejador de la llamada do_system_name().

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

3.3.2- Creación de un lote para correr varios procesos En el directorio /home/test/ se crea un archivo de tratamiento por lote con el objetivo de tener varios procesos corriendo en un determinado tiempo. La implementación de este archivo se muestra en la figura 3.3.

Figura 3.3 Creación de un lote Esta implementación permite correr simultáneamente 15 procesos y ejecuta el archivo de prueba del proceso. La orden proceso & muestra, de fondo, el comienzo de un proceso ejecutándose durante un tiempo determinado y su culminación según se aprecia en la figura 3.4

Figura 3.4 Ejecución del proceso de fondo

3.3.3- Nueva llamada al sistema en el servidor FS En este epígrafe se explica, mediante ejemplos, la implementación de una llamada al sistema en FS, la llamada se nombrará do_printmessage(), y su semántica es bien sencilla, imprimir el mensaje “Nueva llamada implementada en FS para aprender a trabajar con MINIX3”. El índice 69 contiene una entrada sin uso, que se usará para implementar la llamada do_printmessage (). do_printmessage, /* 69 = printmessage */ Primero se declara el prototipo del manejador de la llamada de la siguiente forma: _PROTOTYPE (int do_printmessage, (void));

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Después se agrega la definición de la función do_printmessage en /usr/src/servers/fs/misc.c. Seguidamente se compila el servidor FS. La implementación de la función printmessage () se muestra en la figura 3.5.

Figura 3.5 Código de la nueva llamada sobre FS Se adiciona en /usr/include/minix/callnr.h, donde están asociados los números de las llamadas al sistema con su nombre y en /usr/src/include/minix/callnr.h la expresión: #define PRINTMESSAGE 69

Se crea la función de la biblioteca de usuario para la llamada al sistema do_printmessage () en el archivo _printmessage.c y después se agrega dicho archivo a la lista de compilación en /usr/src/lib/posix/Makefile y en /usr/src/lib/posix/Makefile.in.

Para probar la nueva llamada al sistema se crea, en el directorio /home/test/, el archivo printmessage.c, donde se llamará a la función del manejador de la llamada do_printmessage. Posteriormente se compila el archivo de prueba de la siguiente forma:

cc –o printmessage printmessage.c,

donde printmessage es el archivo ejecutable y printmessage.c es la fuente donde se compila.

Par ver la nueva llamada al sistema debe ejecutarse, en /home/test/, el siguiente código: ./printmessage. El resultado se muestra en la figura 3.6.

Figura 3.6 Ejecución de la nueva llamada al sistema de FS 38

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

3.3.4- Nueva llamada al sistema en el servidor PM La nueva llamada al sistema en el servidor PM deberá retornar el identificador del proceso que la ejecuta (PID) y el identificador del proceso padre (PPID). Para esto deberá crearse una función en el sistema que lleve a cabo la tarea deseada dentro del archivo getset.c y declarar el prototipo de esta función. Luego para que esta función pueda ser utilizada por programas creados por el usuario, tiene que existir una biblioteca, por lo que hay que crear (getpids.c). Una vez implementada la llamada al sistema, tiene que crearse una forma de verificar su funcionamiento, para esto se crea el programa getpids.c, que realiza una comparación entre las funciones nativas del sistema que obtienen el PID y el PPID utilizando la función assert.

Para crear la llamada getpids, se deben llevar cabo los siguientes pasos: 1. Editar el archivo /usr/src/include/minix/callnr.h con el editor mined  Incrementar el número máximo de la llamada (nr_call) de 95 a 96.  Crear la línea "#define GETALLPID 95" al final del archivo. 2. Modificar el archivo /usr/src/servers/pm/proto.h:  Debajo de "/* getset.c */" se crea un prototipo de la llamada que se desea crear: "_PROTOTYPE (int do_getpids, (void));" 3. En el archivo /usr/src/servers/pm/table.c:  insertar la línea "do_getpids, /* 95 = get parent pid and own pid */ (tiene que estar en la posición adecuada, en este caso la posición 95, i gual a lo especificado en el paso 1). 4. En el archivo /usr/src/servers/fs/table.c  insertar la línea "no_sys, /*95 = get parent pid and own pid*/" 5. Editar el archivo /usr/src/servers/pm/getset.c:

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

La figura 3.7 muestra la implementación de la función do_getpids dentro el archivo getset.c

Figura 3.7 Función do_getpids 6. Crear el archivo /usr/src/lib/posix/getpids.c con el código que se muestra en la figura 3.8.

Figura 3.8 Función do_getpids

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

7. Después se agrega el archivo _getpids.c a la lista de compilación en /usr/src/lib/posix/Makefile y en /usr/src/lib/posix/Makefile.in. 8. Se compila la nueva biblioteca y el kernel. 9. Crear el archivo getpids.c en /home/test/ para probar la nueva llamada. 10. Compilar el programa getpids.c incluyendo el código de la nueva biblioteca y ejecutar el archivo binario resultante:

cc –o getpids getpids.c, donde getpids es el archivo ejecutable y getpids.c es la fuente donde se compila.

El resultado de la llamada se muestra en la figura 3.9.

Figura 3.9 Ejecución de la nueva llamada en PM

3.3.5- Implementación de una llamada al sistema para cambiar la prioridad de un trabajo. En este epígrafe se presenta una llamada al sistema con la siguiente sintaxis: int setprity (int pid, int priority); Esta llamada tiene por objetivo que el proceso padre modifique la prioridad del proceso hijo, usando como parámetros el pid del hijo y la prioridad a la que se desea cambiar. Luego de cambiada la prioridad se reubicaría nuevamente en la cola de procesos listos y el hijo enviará un mensaje con la confirmación del cambio de prioridad. Modificaciones realizadas: Se le asigna un número a la llamada en la tabla de procesos: do_setprity, /* 57 = setprity*/ Se define el prototipo del manejador de la llamada de la siguiente forma: _PROTOTYPE (int do_setprity, (void));

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Se define la función do_setprity en el directorio /usr/src/servers/pm/misc.c. La figura 3.10 muestra la implementación de dicha función.

Figura 3.10 Llamada al sistema para cambiar prioridad En /usr/include/minix/callnr.h están asociados los números de las llamadas al sistema con su nombre, aquí se edita callnr.h con: #define SETPRITY 57 En /usr/src/lib/posix están las bibliotecas de Posix, se crea _setprity.c con el código que se muestra en la figura 3.11.

Figura 3.11 Función setprity 42

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Después de hecho esto, se agrega el archivo _setprity.c a la lista de compilación /usr/src/lib/posix/Makefile y a /usr/src/lib/posix/Makefile.in para introducirlo a la lista de compilación. Se compila el servidor PM y luego la biblioteca, para finalmente guardar la nueva imagen del sistema operativo. Por último para verificar el funcionamiento de la llamada, se crea, en /home/test/, un programa de prueba. Este programa será guardado con el nombre setprity.c, se compila y se muestran los resultados que se ilustran en la figura 3.12.

Figura 3.12 Verificación de la nueva llamada en PM La primera sentencia de salida retorna el PID del padre con su prioridad. El hijo envía un mensaje con su PID y su prioridad, luego el padre envía un mensaje para dar a conocer a su hijo que va a cambiarle la prioridad a 2. Luego se escribe un mensaje en el momento que está ocurriendo el cambio, retornando el PID del hijo , la prioridad ya cambiada y un código de salida que, si es 1, es porque ocurrió un error y 0 , si el cambio fue exitoso. Después el hijo envía un mensaje de confirmación, donde muestra su prioridad cambiada.

3.3.6- Llamada al sistema obtener el tiempo de espera de un proceso determinado La nueva llamada al sistema tendrá la siguiente sintaxis: int wtime (int pid); Esta llamada consiste en obtener el tiempo de espera de un proceso en la cola, para ello se siguen los pasos comunes de una llamada al sistema, pero se adiciona otros; pues es necesario reiniciar el reloj cuando un proceso está en estado de listo y contar el tiempo que espera antes de estar listo. Además se mostrará, al ejecutar el comando

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes. ps, el tiempo de espera de cada proceso. A continuación se presentan las modificaciones y los archivos correspondientes. En el archivo proc.h que se encuentra en /usr/src/kernel/proc.h, se modifica la estructura de datos proc incluyendo la variable w_time, para guardar el tiempo de espera de un proceso.

En el directorio /usr/src/kernel/system se modifica el archivo do_fork.c para inicializar w_time en 0.

En clock.c se encuentra el método clock_handler. Clock_handler conocido como el manejador de interrupción de reloj, actualiza prev_ptr con proc_ptr si el proceso actual ha consumido su quantum, avisando a la tarea de reloj (lock_notify) y activándose por ello do_clocktick.

Se modificará este método para incrementar en uno cada tick de reloj y así poder contar el tiempo que estuvo el proceso en la cola, cuando el proceso pasa a la CPU entonces el tiempo se reinicia a 0. En la figura 3.13, se muestra dicha modificación.

Figura 3.13 Conteo del tiempo Se le asignó un número a la llamada en la tabla de procesos, el cual se muestra a continuación: do_wtime, /* 58 = wtime*/

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Se definió el prototipo del manejador de la llamada de la siguiente forma: _PROTOTYPE (int do_wtime, (void)); Luego, para no generar otro archivo, se puede usar el misc.c. En este archivo se implementó la rutina do_wtime encargada de la recepción de los mensajes WTIME a nivel del Memory Manager, como se muestra en la figura 3.14.

Figura 3.14 Función do_wtime

En /usr/include/minix/callnr.h están asociados los números de las llamadas al sistema con su nombre, aquí se edita callnr.h con: #define WTIME 58 Se creó el archivo _wtime.c en /usr/src/lib/posix con el objetivo de implementar la función wtime que es la encargada de pasar el mensaje al MM, dicha implementación se muestra en la figura 3.15.

Figura 3.15 Función wtime 45

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Después de hecho esto se agrega el fichero _wtime.c a la lista de compilación en /usr/src/lib/posix/Makefile y en /usr/src/lib/posix/Makefile.in. Se compila el servidor PM y luego la biblioteca, para finalmente guardar la nueva imagen del sistema operativo. Se crea, en /home/test/, un programa para verificar el funcionamiento de la nueva llamada. Este programa será guardado con el nombre wtime.c. Para saber los ticks de reloj que le faltan a un proceso en la cola, debe ejecutarse ./wtime PID, donde PID no es más que el pid de alguno de los procesos que se muestran en la pantalla al ejecutar el comando ps. En la figura 3.16 se muestra un ejemplo de lo anteriormente expresado. En este ejemplo se ejecuta primeramente el lote para tener varios procesos corriendo y luego se pone a prueba la nueva llamada wtime.

Figura 3.16 Prueba de la nueva llamada

3.3.6.1- Modificación del comando ps para incluir el tiempo de espera de un proceso El comando ps, muestra la lista de procesos que están corriendo. El objetivo que se persigue es agregarle una nueva funcionalidad para que informe el tiempo de espera de un proceso en la cola, para eso se hicieron las siguientes modificaciones: El código del comando ps se localiza en /usr/src/commands/ps/ps.c. 1. La constante S_HEADER contiene la estructura del comando o sea: #define S_HEADER “PID TTY TIME CMD\n” Debe agregársele el nombre que representará el tiempo de espera: 46

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

#define S_HEADER “PID TTY TIME WTIME CMD\n”

2. Luego se edita S_FORMAT que contiene el formato de salida del comando ps de la siguiente manera:

#define S_FORMAT "%5s %3s %s %s %s\n" 3. En ps se define la estructura de datos pstat. A continuación se muestran algunos campos que se definen en esta estructura. Es importante conocer que struct pstat se va llenando mediante el método pstat () implementado en este mismo archivo.

4. Se adiciona, en el método main del archivo ps.c, un arreglo de char llamado swtime para llevar el tiempo de espera de un proceso de usuarios en la cola de procesos, donde se define el tamaño del reloj.

5. Luego en el ciclo for que imprime el formato del comando se hace la llamada a wtime (buf.ps_pid). De esta forma al ejecutar el comando ps se mostrará, además de los datos que son propios del comando, el tiempo de espera de cada proceso. La figura 3.17 muestra el tiempo de espera de todos los procesos que están corriendo al ejecutar ps. Para ver bien los tiempos se ejecuta primero un lote de procesos.

Figura 3.17 Ejecución de ps modificado 47

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

3.3.7- Implementación de una llamada al sistema para eliminar un proceso de acuerdo al mayor tiempo de CPU El objetivo es desarrollar una llamada al sistema con la siguiente sintaxis: int killp (void); La llamada debe eliminar el proceso que mayor tiempo lleve en la cola de procesos, es decir eliminar el proceso que menos tiempo haya estado en la CPU. Esta función no tiene parámetros, aunque siempre se auxiliará de su PID. La llamada elimina (kill) al proceso si su PID es mayor que cero, sino entra en un ciclo tratando de eliminar algún proceso del sistema como una tarea o servidor. Nunca se elimina ni una tarea del sistema, ni un servidor para eso se utiliza el método check_sig que hace una selección entre los privilegios de cada proceso. Retorna 0 si ha ocurrido algún error.

Cambios realizados: Se le asignó un número a la llamada en la tabla de procesos, el cual se muestra a continuación: do_killp, /* 70 = killp */ Se definió el prototipo del manejador de la llamada de la siguiente forma: _PROTOTYPE (int do_killp, (void)); Se definió la función do_killp en el directorio /usr/src/servers/pm/signal.c. La figura 3.18, muestra la implementación de dicha función. En esta implementación se define a proctab como un arreglo de la estructura proc, para almacenar la tabla de procesos. La llamada sys_getproctab es un apuntador a un arreglo de la estructura proc que se utiliza para ir almacenando la tabla de procesos. Se utiliza la llamada wtime, ya que esta guarda el tiempo del proceso en la cola.

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Figura 3.18 Función para eliminar procesos

El fragmento señalado en negro es para establecer que el proceso se elimine si el PID es mayor que 0.Pero en MINIX 3 existe un problema con el PID en la estructura de procesos en el kernel, este no aparece definido, por eso se optó por moverse por la tabla de procesos e ir obteniendo el número de cada proceso, que no es más que el índice que ocupa en la tabla de procesos que coincide para los procesos del kernel y el manejador de procesos y de ahí se obtiene el PID. En /usr/include/minix/callnr.h están asociados los números de las llamadas al sistema con su nombre, aquí se edita callnr.h con: #define KILLP 70 En /usr/src/lib/posix están las bibliotecas de posix se crea _killp.c, después, se agrega el archivo _killp.c, a la lista de compilación /usr/src/lib/posix/Makefile y en /usr/src/lib/posix/Makefile.in. Posteriormente se compila el servidor PM y luego la biblioteca, para finalmente guardar la nueva imagen del sistema operativo.

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Se crea, en /home/test/, el archivo killp.c y se compila el programa de prueba. Los resultados se muestran en la figura 3.19.

Figura 3.19 Prueba de la nueva llamada para eliminar procesos Puede observarse que cuando se ejecuta ps, el proceso con PID 105 no aparece en la lista porque ya ha sido eliminado.

3.3.8- Documentación de las nuevas llamadas al sistema En los SO de la familia UNIX, el comando man (manual) brinda una ayuda a acerca de cada uno de los comandos y llamadas al sistema, para obtener la ayuda basta con ejecutar el comando man y pasarle, como parámetro, el nombre de lo que se desea consultar, ejemplo: man ps Cuando se agrega una nueva llamada al sistema o un comando debe agregarse alguna ayuda acerca de las nuevas facilidades, en esta sección se hace una descripción de la forma en que se ha logrado ese objetivo.

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Para adicionar la ayuda acerca de las nuevas facilidades, debe seguirse el formato de la plantilla que se muestra en la 3.20.

Figura 3.20 Plantilla de formato para el man La plantilla utiliza las siguientes etiquetas: SH para los títulos de cada nombre como por ejemplo NAME, SYNOPSIS. \fI parámetros\fP para resaltar con el color azul los parámetros de la función. .B para resaltar el nombre de la llamada. Esta plantilla se guarda en un archivo con extensión .2 que se ubicará en /usr/src/man/man2, ya que aquí se encuentran todas las llamadas al sistema. Una vez hecho esto debe compilarse el archivo, para lo cual puede usarse la técnica de cambiarse al directorio /usr/src/man y ejecutar el comando “make” y luego “make install”. Como este no es un archivo fuente, no tiene sentido compilarlo como se ha hecho en los demás casos. Una vez hechas las modificaciones, en donde se han incluido los detalles de la ayuda de acuerdo a las distintas secciones del man, se puede acceder a ella de la misma manera que se hace con las llamadas que vienen con el SO. La figura 3.21 muestra el resultado de pedir la ayuda acerca de la llamada getpids.

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Figura 3.21 Ejecución del comando man para la nueva llamada

3.4- Planificación de procesos La planificación de procesos es la base de todo sistema operativo que use multiprogramación. Ella permite un mayor aprovechamiento del procesado. El objetivo de la multiprogramación es tener varios procesos ejecutando a la vez con el propósito de maximizar el uso de la CPU, por otra parte el objetivo de los sistemas de tiempo compartido (time sharing) es intercambiar la CPU entre distintos procesos tan frecuentemente que los usuarios perciban la idea de que todos los procesos están ejecutándose a la vez (Tanenbaum y Woodhull,2006). Con el fin de lograr estos objetivos el sistema operativo cuenta, como uno de sus módulos, con el planificador de procesos, el cual tiene la tarea de seleccionar (entre los procesos listos) el próximo proceso al que se le asignará la CPU.

3.4.1- Tipos de planificadores En un sistema operativo complejo existen hasta tres tipos de planificadores diferentes, cada uno de ellos con una función distinta, dentro del contexto de su trabajo en el sistema. Otros sistemas operativos más sencillos no implementarán los tres, o tenderán a juntar algunas funciones de los tres en un único planificador sencillo (Stallings,1997).

- Planificador de período largo: La tarea del planificador de período largo es escoger los nuevos trabajos y cargarlos a memoria para ponerlos como

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

candidatos a ejecutar. Este planificador no es frecuente en sistemas Windows ni Unix. El planificador de período largo (conocido también como planificador de trabajos) se ejecuta con menor frecuencia que los demás planificadores y es el responsable de mantener una buena mezcla de trabajos combinando procesos que usan mucho la CPU con otros que la usan poco.  El planificador de período corto: Su tarea es escoger, de la cola de listos, cuál será el próximo proceso a ejecutar para después comunicarle su decisión al despachador, el cual se encargá de darle el control de la CPU al proceso escogido. - El planificador de período medio: Algunos sistemas operativos adicionan este planificador que tiene la función de disminuir el grado de multiprogramación cuando así lo entiende para lo cual extrae algún proceso de memoria y de su actividad con la CPU.

3.4.2- Algoritmos de planificación de procesos Existen dos enfoques de planificación de la CPU, el primero sin desalojo (nonpreemtive), que son los llamados sistemas operativos cooperativos. La característica fundamental de los sistemas de este tipo está en que los procesos ceden voluntariamente la CPU, cuando no la están usando, ejemplo: Windows 3.11. Esta idea no es equitativa pues si el proceso demora en abandonar la CPU un tiempo considerable, otros procesos se verán afectados. Algunos de los algoritmos de planificación de la CPU sin desalojo son:

1) El primero que llega es el primero en ser servido (FCFS) (Tanenbaum y Woodhull,1997). 2) El primer trabajo más corto (SJF) (Stallings,1997, Tanenbaum y Woodhull,2006). 3) Algoritmo por prioridades con desalojo o sin desalojo (Tanenbaum y Woodhull,2006). 4) Colas de prioridades múltiples. 5) Shortest Remaing Time (SRT) (Stallings,1997).

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

El segundo de los enfoques es con desalojo (preemtive), este consiste en dar el procesador a un proceso determinado por un tiempo determinado. Al cabo de ese tiempo se lo quita sin importar en qué momento del procesamiento se encuentra.

Algunos de los algoritmos de planificación de la CPU con desalojo son:

1) Round Robin (torneo) (Tanenbaum y Woodhull,1997). 2) Colas múltiples (Tanenbaum y Woodhull,1997). 3) Colas multinivel con retroalimentación (Tanenbaum y Woodhull,2006). 4) Menor tiempo restante (Stallings,1997). 5) Highest Response Ratio Next (HRRN) (Stallings,1997).

3.5-Los procesos en el SO MINIX 3 A diferencia de UNIX, cuyo núcleo es un programa monolítico, MINIX 3 es un núcleo formado por una colección de procesos que se comunican entre sí y con los procesos de usuario mediante una única primitiva de comunicación interproceso: envío de mensajes. Este diseño proporciona una estructura más modular y flexible, lo cual hace que sea sencillo, por ejemplo, cambiar completamente el sistema de archivos sin que sea necesario ni siquiera recompilar el kernel (Tanenbaum y Woodhull,2006).

3.5.1- Planificación de procesos en SO_MINIX3

El planificador de MINIX 3, usa un sistema de colas multinivel. Se definen 16 colas como se muestra en la figura 3.22, aunque se puede recompilar fácilmente para usar más o menos (Tanenbaum y Woodhull,2006).

Figura 3.22 Colas de procesos en MINIX 3 54

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

El arreglo rdy_head tiene una entrada por cada cola y cada entrada apunta al proceso que está a la cabeza de la cola correspondiente. De forma similar rdy_tail es un arreglo cuyas entradas apuntan al último proceso de la cola.

La cola de prioridad más baja sólo está ocupada por el proceso IDLE que corre cuando no hay otra cosa que hacer. Las prioridades, en un principio, respetan la siguiente desigualdad.

IDLE < procesos de usuario < servidores < drivers < tareas

Los procesos de usuario arrancan en una cola varios niveles por encima de la más baja. Los servidores se planifican en colas con mayor prioridad en general que la permitida a los procesos de usuario, los drivers tienen prioridades mayores a los servers. La tarea del reloj y la tarea del sistema se planifican en la cola de la más alta prioridad. Dentro de cada cola se aplica el turno circular.

El quantum10 es otro parámetro que permite privilegiar a algunos procesos. Los procesos de usuario tienen un quantum relativamente pequeño.

Los drivers y los servers deben correr hasta que se bloqueen, sin embargo, como una barrera contra los defectos de funcionamiento, se hacen “desalojables” aunque poseen un quantum grande, permitiéndole correr a lo largo de varios ticks de reloj pero desalojándolos si consumen mucho tiempo para no bloquear el sistema.

Los procesos que se desalojan se consideran listos y se ponen al final de su cola de prioridad. Sin embargo, si un proceso, que gastó su quantum es el último que corrió, puede ser una señal que está en un ciclo y de esa manera está impidiendo que los procesos de prioridad inferior puedan disponer de la CPU. En este caso su prioridad se disminuye y se pone al final de una cola de más baja prioridad. Si el proceso termina su quantum de nuevo y hay otros procesos que no han tenido la oportunidad de correr, su prioridad se disminuye otra vez. Eventualmente, otro proceso tendrá la oportunidad de correr (Tanenbaum y Woodhull,2006).

10 quantum: intervalo de tiempo que se le asigna a un proceso durante el cual puede ejecutarse. 55

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Un proceso que ha sido degradado en su prioridad, puede ganarse su antigua cola de prioridad. Si un proceso acaba su quantum pero no impide que otros procesos corran, se promueve a una cola de mayor prioridad, hasta la máxima que tiene permitida. Tales procesos necesitan su quantum, pero no son desconsiderados con los demás.

En otros casos, los procesos se planifican mediante una versión ligeramente modificada de Round Robin. Si un proceso no ha utilizado todo su quantum cuando deja de estar listo, se asume que se ha bloqueado esperando por E/S, y cuando queda listo se pone a la cabeza de la cola, pero sólo con la parte restante de su quantum de tiempo. Esto se hace para dar una rápida respuesta a la E/S de los procesos de usuario. Si un proceso sale del estado listo porque acabó su quantum de tiempo se coloca al final de su cola, al más puro estilo Round Robin (Tanenbaum y Woodhull,2006).

Con este arreglo, las tareas tienen la más alta prioridad, los drivers le siguen, los servidores a continuación, y por último los procesos de usuario. Se deduce que los procesos de usuario no van a correr a menos que ninguno de los procesos del sistema no tengan nada que hacer y además se ve que nunca un proceso del sistema va a quedarse sin CPU por culpa de un proceso de usuario.

Cuando se elige un proceso para ejecutar, el planificador verifica antes que no haya ningún proceso anclado en una cola de mayor prioridad. Si uno o más están listos, el que está a la cabeza de la cola se corre. Si no hay ninguno listo, se verifica en la cola de inmediata prioridad inferior y así se sigue. Como los drivers responden a las solicitudes de los servidores y los servidores responden a las solicitudes de los procesos de usuario, eventualmente todos los procesos de alta prioridad completarán el trabajo que le han solicitado. En ese momento se bloquean hasta que los procesos de usuario tienen la oportunidad de correr y así de hacer más solicitudes. Si ningún proceso está listo, se elige el proceso IDLE. Esto pone a la CPU en modo de bajo consumo hasta que ocurre la siguiente interrupción.

En cada tick del reloj se verifica para saber si el proceso actual ha corrido por más tiempo del quantum que tenía asignado. Si eso sucede, el planificador lo mueve al

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes. final de su cola (lo cual no requiere nada de esfuerzo si es el único en la cola). El proceso desalojado vuelve a correr inmediatamente solamente en el caso que esté solo en su cola y que no haya ningún proceso listo en las colas de mayor prioridad. Si no, el proceso que corre es el que está a la cabeza de la cola no vacía de mayor prioridad. Los drivers y los server esenciales disponen de quantum tan largos que normalmente nunca son desalojados por el reloj. Pero si algo sale mal, su prioridad puede disminuirse para evitar que el sistema se detenga completamente. Si esto le sucede a un servidor esencial, es probable que no se pueda hacer nada para recuperar el sistema, pero al menos se puede recolectar información para una posterior depuración y apagar ordenadamente el sistema para evitar la pérdida de datos.

3.5.2- Implementación de la planificación en SO MINIX3 Todo proceso en el SO MINIX 3 se representa por una estructura definida en el fichero de cabecera proc.h que se encuentra en la siguiente dirección /usr/src/kernel. El fichero proc.h contiene la definición de la tabla de procesos (del núcleo). Cada entrada en la tabla de procesos respeta la estructura struct proc que posee los campos que se muestran en la figura 3.23.

Figura 3.23 Campos de la estructura proc

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Se definen constantes que son utilizadas por los elementos definidos en la estructura proc, como por ejemplo para el elemento p_rts_flags se definen las siguientes constantes: - SLOT_FREE /* si el proceso no está en uso */ - NO_MAP /* evita que el procesos hijo se ejecute antes de haber preparado su mapa de memoria */ - SENDING & RECEIVING /* indican que el proceso está bloqueado tratando de enviar y recibir un mensaje */ - P_STOP /* sirve como apoyo para el rastreo durante la depuración */ - NO_ENDPOINT /* los procesos no pueden recibir, ni enviar mensajes */ - NO_PRIORITY /* procesos han sido parados */ Además se define la tabla de procesos como un arreglo a esta estructura con la siguiente sintaxis proc [NR_TASKS + NR_PROCS], donde NR_TASKS se define en el archivo com.h del directorio /usr/src/include/minix/ y la constante NR_PROCS en el fichero config.h del directorio /usr/src/include/minix/. Como la tabla de procesos es accedida frecuentemente para calcular la dirección del arreglo para ubicar, se define pproc_addr, que no es más que una estructura de punteros a la tabla de procesos. Los dos arreglos rdy_head y rdy_tail sirven para mantener las colas de planificación, como por ejemplo rdy_head apunta al primer proceso de la tabla de tareas. Para introducir o extraer procesos de una cola de procesos existen las funciones enqueue y dequeue (/usr/src/kernel/proc.c), utilizadas por ejemplo en mini_send, mini_receive y mini_notify.

Enqueue:

 Tiene como parámetro un puntero a una entrada en la tabla de procesos.  Determina donde insertar el proceso llamando a sched, el cual devuelve la cola en la que debe introducirse y si debe hacerlo por el principio o el final.  Introduce el proceso en el lugar indicado.  Se llama a pick_proc para planificar a un proceso.

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Dequeue:

 Tiene como parámetro un puntero a una entrada en la tabla de procesos.  Busca y elimina el proceso indicado de la tabla de procesos.  Si el proceso eliminado era el que estaba ejecutándose se llama a pick_proc para seleccionar a otro proceso.

Sched verifica, en primer lugar, si el proceso suministrado como parámetro ha consumido su quantum. De ser así le baja la prioridad salvo que sea la mínima. Si el proceso no ha consumido su quantum se le introduce al principio de la cola de prioridad marcada por la prioridad actual del proceso.

Pick_proc únicamente busca el proceso listo al principio de la cola de mayor prioridad. Si no hay ninguno, IDLE siempre está listo, al final actualiza next_ptr que es utilizado por restart.

El manejador de interrupción de reloj, clock_handler (clock.c), actualiza prev_ptr con proc_ptr si el proceso actual ha consumido su quantum, avisando a la tarea de reloj (lock_notify), activándose por ello do_clocktick. Si el proceso actual es expulsable y ha consumido su quantum de tiempo, do_clocktick lo reubica en las colas de procesos activos llamando a dequeue y seguidamente a enqueue.

3.5.3- Modificación al algoritmo de planificación de MINIX3

Se modificó el algoritmo de planificación de MINIX 3 para privilegiar a los procesos que mayor tiempo hayan estado en la cola de listos. Modificaciones realizadas: 1. Se define en la estructura proc ubicada en el archivo proc.h del directorio /usr/src/kernel/: - La constante UCLV de la siguiente manera:

- La variable cpu_time para almacenar el tiempo de CPU de un proceso.

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

La constante UCLV se define para diferenciar las modificaciones propias de las de MINIX 3. 2. Se modificó el código del método pick_proc del archivo proc.c ubicado en el camino /usr/src/kernel/. En la figura 3.24 se muestra un fragmento de la modificación.

Figura 3.24 Modificación de pick_proc Se puede apreciar cómo se utiliza nuevamente #ifdef UCLV para señalar el código propio. La modificación que se hizo consiste en hacer una búsqueda en las colas de procesos, e ir comparando la variable min_cpu con cpu_time. Si cpu_time es menor que min_cpu entonces se guarda cpu_time y se pasa a comparar con el otro proceso en la cola, sino se sigue recorriendo la cola de procesos. 3. Se adicionó en el archivo do_fork del directorio /usr/src/kernel/system el siguiente fragmento de código, que lo que hace es reiniciar cpu_time a 0, cuando el proceso pasa a ejecutarse.

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Para comprobar la modificación, se ejecutan dos lotes de procesos como se muestran en la figura 3.25.

Figura 3.25 Ejecución de dos lotes de procesos La diferencia de la modificación con el algoritmo original del planificador de MINIX 3, se puede ver al ejecutar dos lotes de la siguiente manera: - Esta modificación le da una oportunidad a los procesos que menos tiempo de CPU poseen, lo que permite que los procesos hagan un uso parejo de la CPU, provocando que los procesos de los lotes terminen simultáneamente (ver figura 3.26), mientras que con el algoritmo de planificación de MINIX 3, terminan los procesos en el orden que fueron ejecutados.

Figura 3.26 Ejecución de nuestra modificación

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

3.5.4- Modificación al algoritmo de planificación de MINIX3 para FCFS Se modificó el algoritmo de planificación de MINIX 3 para FCFS (First Come First Server). Este algoritmo consiste en ejecutar el primer proceso que llega a la cola. Modificaciones realizadas: 1) Se define en la estructura proc ubicada en el archivo proc.h del directorio /usr/src/kernel/: - La constante UCLVFCFS para identificar esta nueva modificación de la siguiente manera:

La constante UCLV se indefine para poder correr esta nueva modificación dentro del kernel sin intervenir en el algoritmo de planificación del MINIX 3, ni en la anterior modificación. 2) Se modificó el código del método sched del archivo proc.c ubicado en el camino /usr/src/kernel/, agregándole el siguiente código, para que front retorne 0 si es la modificación propia, garantizando que no se escoja otro proceso a ejecutar, sino ha terminado el que se ejecuta actualmente.

3) Se adicionó en el método do_clocktick del archivo clock.c en el directorio /usr/src/kernel/ el siguiente fragmento de código (ver figura 3.27), que reubica procesos en las colas de procesos activos llamando a dequeue para extraerlo cuando ya ha sido ejecutado y seguidamente a enqueue para reinsertar el siguiente en la cola.

Figura 3.27 Modificación realizada al archivo clock.c

Capítulo III Arquitectura del MINIX. Transformaciones a sus componentes.

Para ver la ejecución de la modificación para FCFS, se ejecuta un lote de procesos, como se muestra en la figura 3.27. Esta modificación se diferencia de las anteriores ya que FCFS sirve al primer proceso de la cola, y no pasa a ejecutar otro hasta que no termina con el elegido anteriormente. En la figura 3.28 se ve como va ejecutando los procesos de uno en uno, en el orden en que fueron entrando y no pasa a ejecutar otro proceso hasta que no termine con el anterior.

Figura 3.28 Ejecución de la modificación FCFS

3.6- Resumen del capítulo El capítulo abordó los siguientes aspectos: 1- Implementación de nuevas llamadas al sistema. 2- Modificaciones al planificador. 3- La modificación del comando ps para incluir el tiempo de espera de un proceso en la cola. 4- La inclusión de las nuevas llamadas a sistema en las páginas del manual interactivo (MAN).

Conclusiones

Conclusiones Con la realización del presente trabajo se da respuesta a la necesidades planteadas por el Grupo de Informática Educativa de la UCLV de disponer de una nueva versión del Sistema Operativo MINIX 3, de documentar los módulos del sistema y obtener una guía de estudio que permita realizar modificaciones al sistema por los estudiantes del tercer año de la carrera Lic. Ciencia de La Computación. Se logra dar cumplimiento al objetivo planteado a partir de que: 1- Se diseñó e implementó una nueva versión del sistema operativo MINIX 3. 2- Se confeccionó un conjunto de documentos que sirven de guía para que los estudiantes puedan hacer modificaciones al SO. 3- Se documentaron las modificaciones hechas al SO y en el caso de las llamadas al sistema se incluyen en las páginas de ayuda (man).

Recomendaciones

Recomendaciones Se presentan las siguientes recomendaciones: 1- Adicionar nuevas llamadas al sistema para que trabaje con procesos de fondo, es decir una llamada que sea capaz de cambiar un proceso de background a foreground. 2- Modificar el planificador de MINIX para que trabaje con otros algoritmos de planificación. 3- Extender a MINIX 3 para las arquitecturas de SMP, modificación realizada a otras versiones de MINIX.

Referencias Bibliográficas

[1] Brito, M. L. 2007. Guía del Laboratorio de SO. [2] Caballero, F. (2006). Implementación de un System Call in Minix 3. [3] Chernich, R., Jamieson, B. y Jones, D. (2003). "Yet Another Teaching Operating System". The Weblog of (A) David Jones [En línea]. Disponible en: http://davidtjones.wordpress.com/publications/rcos-yet- another-teaching-operating-system/. [4] Christopher, W. A., Procter, S. J. y Anderson, T. E. (1993). The Nachos Instructional Operating System. Proceedings of the Winter 1993 Usenix Technical Conference Disponible en: http://www.cs.washington.edu/homes/tom/nachos/. [5] Fankhauser, G., Conrad, C., Zitzler, E. y Plattner, B. (2000). Topsy: A Techeable Operating System. Computer Engineering and Networks Laboratory, ETH Zürich. [6] Grabczewski, E. y Liu, X. (1993). DYNAMIX: an Operating System Teaching Assistant. Birkbeck College,University of London. [7] Infórmatica, E. U. D. (2010/2011). "Toma de contacto con MINIX ". [8] Jayaraman, K. (2006). How to add a new system call for Minix 3. Departament of Electrical Engineering & Computer Science, Syracuse University. [9] Llorente, J. M. Á., Martín, J. C. D. y García, J. M. R. (2002). "Extendiendo Minix a Arquitecturas SMP". XIII Jornadas del paralelismo. [10] Mes 2007. Plan de Estudio D para la carrera Lic. Ciencia de la Computación. Ciudad de La Habana. [11] Meurs, R. (2006). Building Performance Measurement Tools for the Minix3 Operating System. [12] Mikelats. (2009 ). "Llamada al sistema". Informática: algo más que bits [En línea]. [13] Mit. (2002). Xv6, a simple UNIX-like teaching operating system. [14] Pfaff, B. (2004). Pintos [En línea]. Universidad de Stanford. Disponible en: http://www.scs.stanford.edu/10wi- cs140/pintos/pintos_1.html. [15] Rodríguez, E., Daniel, T. y Quintero, E. (2010). "Sistemas Operativos". [16] Silberschatz, A., Galvin, P. B. y Gagne, G. (2005). Operating Systems Concepts, Yale, University,Corporate Technologies,Westminster College,John Wiley&Songs,Seven Edition [17] Snatverk. (2009). "Instalar Minix 3 en VirtualBox". Snatverk: programación, bases de datos, linux, redes, etc.. [En línea]. [18] Stallings, W. (1997). Sistemas Operativos, Madrid,Prentice Hall,Second Edition. [19] Tag. (2011). "Sistema Operativo Minix 3". De todo un poco [En línea]. Disponible en: http://www.miarroba.com. [20] Tanenbaum, A. S. (2006). Discusión de Tanenbaum-Torvalds. Vrije Universitiet parte II. [Accesado el día 12-15 de mayo del 2006].

Referencias Bibliográficas

[21] Tanenbaum, A. S. y Woodhull, A. S. (2006). Operating Systems Design and Implementation, Vrije Universiteit Amsterdam, The Netherlands [22] Hampshire College, Amherst, Massachusetts,Prentice Hall,Third Edition. [23] Tejo, O. D. A. (2011). Sistemas Operativos Microkernel [En línea]. Disponible en: http://chsos20092.wikispaces.com.

Recomendaciones