1)Qu diferencia hay entre la system call fork() y las exec() (de cualquier de sus versiones, pe exelp())?

Responda en base a un ejemplo de cdigo. Indique en su respuesta el contenido antes y despus de la ejecucin de las reas PCB, TXT y U_AREA. Describa el funcionamiento de la system call exec(), explicando su efecto sobre las estructuras de datos del proceso que la emite (Process Control Block, U-File Table, UArea, BSS (rea static), Txt, Stack).
> > ---> > > > Describa el funcionamiento de la system call exec() Qu instruccin se > > ejecuta a > > continuacin de un exec() ? > > exec( ) cambia el codigo (txt) de este proceso por el contenido de un archivo ejecutable. Si el ecxec() tiene exito la proxima instruccion es la primera del archivo ejecutable. No vuelve al programa que hizo el exec() no confundir con system() que corre el programa como subrutina. Ver el Laboratorio de Procesos y Threads

Un proceso en Unix puede crear un nuevo proceso mediante la llamada al sistema fork(). El nuevo proceso consta del espacio de direcciones del procesos original. Este mecanismo permite al proceso padre comunicarse fcilmente con su proceso hijo. Ambos procesos cuntinuan la ejecucin en la instruccin que sigue a fork(), con una diferencia: el cdigo de retorno para fork() es cero en el caso del proceso nuevo, mientras que al padre se le devuelve el identificador de proceso (distinto de cero) del hijo. Normalmente el proceso hijo utiliza la llamada al sistema exec() con el fin de sustituir el espacio de memoria del procesos con un nuevo programa. La llamada al sistema exec() carga un archivo binario en memoria (destruyendo la imagen en memoria del programa padre) e inicia su ejecucin. De esta manera los dos procesos pueden seguir por caminos diferentes. El padre puede crear mas hijos o, si no tiene nada que hacer mientras se ejecuta el hijo, puede ejecutar una llamda al sistema wait() para auto-exluirse de la cola de procesos preparados hasta que el proceso hijo se complete.

Nota1: recordar que la imagen del proceso es la misma para ambos programas luego de ejecutarse fork(). Nota2: recordar que luego de ejecutarse fork() en el proceso hijo se retorna 0 y en el padre un numero mayor a 0;

Que es el U_Area ? In addition to the text, data, and stack segment, the OS also maintains for each process a region called the u area (User Area). The u area contains information specific to the process (e.g. open files, current directory, signal action, accounting information) and a system stack segment

for process use. If the process makes a system call (e.g., the system call to write in the function in main ), the stack frame information for the system is stored in the system stack segment. Again, this information is kept by the OS in an area that the process doesn't normally have access to. Thus, if this information is needed, the process must use special system call to access it. Like the process itself, the contents of the u area for the process are paged in and out bye the OS.

Para implementar el modelo de los procesos el sistema operativo mantiene una tabla (un array de registros o estructuras), denominada la tabla de procesos, con una entrada por proceso.

Algunos autores denominan a cada una de esas entradas descriptor de proceso o bloque de control de proceso(BCP). Estas entradas contienen informacin sobre el estado de cada proceso, su contador de programa, su puntero de pila, su asignacin de memoria, el estado de sus ficheros abiertos, la informacin relativa a su planificacin y a la contabilidad de los recursos que ha consumido, as como cualquier otra informacin sobre el proceso que deba guardarse cuando el proceso conmute del estado de en ejecucin al estado de preparado o bloqueado, de forma que su ejecucin pueda retomarse posteriormente como si nunca se hubiera detenido. Una vez presentada la tabla de procesos, es posible precisar un poco ms cmo es posible ofrecer la ilusin de la existencia de mltiples procesos secuenciales que desarrollan su actividad concurrentemente, sobre una mquina con una nica CPU y muchos dispositivos de E/S. Cada clase de dispositivos de E/S (como por ejemplo las disqueteras, los discos duros, los timers o los terminales) tiene asociada una posicin de memoria (a menudo situada en las posiciones ms bajas de la memoria) que se denomina el vector de interrupcin utilizado por ese tipo de dispositivos. Esta posicin de memoria contiene la direccin de la rutina de tratamiento de la interrupcin que atiende a ese tipo de dispositivos. Supongamos que el proceso de usuario nmero 3 se est ejecutando cuando de repente la CPU recibe una interrupcin del disco duro. En ese momento el hardware de las interrupciones apila (en la pila actual) el contador de programa del proceso de usuario nmero 3, la palabra de estado del programa (es decir su registro de estado) y posiblemente algunos otros registros hardware mas. A continuacin la CPU salta a la direccin especificada en el vector de interrupcin del disco. Eso es todo lo que hace el hardware. Desde ese momento toma el control el software, ms concretamente la rutina de tratamiento de la interrupcin. Todas las interrupciones comienzan salvando los registros (a menudo en el descriptor del proceso actualmente en ejecucin). A continuacin se desapila la informacin apilada anteriormente por el hardware (en el momento de la interrupcin), establecindose el puntero de pila para que apunte a una pila temporal utilizada por el proceso controlador (en este caso del disco). Las acciones anteriores, tales como salvar los registros y establecer el puntero de pila, no pueden expresarse en lenguajes de alto nivel como C, de manera que las realiza una pequea rutina en lenguaje ensamblador, usualmente la misma para todas las interrupciones ya que el trabajo de salvar los registros es siempre el mismo, sin importar cul sea la causa de la interrupcin. Cuando esta rutina termina, realiza una llamada a un procedimiento en C para llevar a cabo el resto del trabajo para este tipo de interrupcin especfico. Estamos suponiendo que el sistema operativo est escrito en C (que es la eleccin usual para todos los sistemas operativos reales). Cuando ese procedimiento termina su trabajo, posiblemente provocando que algn proceso pase al estado de preparado, se llama al planificador para determinar qu proceso preparado se ejecuta a continuacin. Despus de eso, se devuelve el control al cdigo en lenguaje ensamblador para cargar los registros y el mapa de memoria del nuevo proceso que ha seleccionado el planificador y se retoma su ejecucin. En la Figura 2-5 se resume el tratamiento de las interrupciones y la planificacin. Es necesario insistir en que los detalles varan considerablemente de un sistema operativo a otro.

2)Cmo se crea un proceso en Windows? Qu bloques de control se usan?

En Windows, donde mediante una nica llamada al sistema de Win32, CreateProcess, se realiza tanto la creacin del proceso como la carga del

programa correcto dentro del nuevo proceso. Esta llamada tiene 10 parmetros que incluyen entre ellos el programa que hay que ejecutar, los parmetros de la lnea de comandos que va a recibir el programa, varios atributos de seguridad, bits que controlan si se heredan los ficheros abiertos, informacin sobre la prioridad del proceso, una especificacin de la ventana que hay que crear (en su caso) para el proceso, y un puntero a una estructura (un registro) en la que se enve de retorno toda la informacin sobre el nuevo proceso creado, al proceso que hace la llamada. Adicionalmente a CreateProcess, Win32 cuenta con unas 100 llamadas al sistema ms, para gestionar y sincronizar los procesos, as como para operaciones relacionadas.

3.) Cundo un proceso est en estado Zombie? Describa una forma de lograrlo
Tras la creacin de un proceso comienza su ejecucin realizando el trabajo que se le ha encomendado. Sin embargo nada dura para siempre, ni siquiera los procesos. Pronto o tarde el nuevo proceso debe terminar, usualmente debido a una de las siguientes causas: 1. El proceso completa su trabajo y termina (voluntariamente). 2. El proceso detecta un error y termina (voluntariamente). 3. El sistema detecta un error fatal del proceso y fuerza su terminacin. 4. Otro proceso fuerza la terminacin del proceso (por ejemplo en UNIX mediante la llamada al sistema kill).

Un proceso que termina no puede abandonar el sistema hasta que su padre acepte su cdigo de retorno. Si el proceso padre ya est muerto, es adoptado por el proceso ``init'' el cual siempre acepta los cdigos de retorno de sus hijos. Sin embargo, si el proceso padre est vivo pero nunca ejecuta un wait(), el cdigo de retorno del proceso nunca ser aceptado y tal proceso se convierte en zombie. Un proceso zombie no tiene ni cdigo, ni stack, ni datos, pero continua habitando en la tabla de procesos (que es de tama o fijo)

4) Discuta la implementacin de threads en el espacio del usuario y en

el espacio del kernel. Explique como influye sobre el scheduler y sus consecuencias para la performance de un sistema programado con varios threads.

Existen dos formas fundamentales de implementar un paquete de threads: en el espacio del usuario y en el ncleo (kernel). El primer mtodo consiste en poner el paquete de threads enteramente en el espacio de usuario. En consecuencia el ncleo del sistema no sabe nada de su existencia. En lo que concierne al ncleo, slo se gestionan procesos ordinarios con un nico thread. La primera, y ms obvia, ventaja es que el paquete de threads a nivel de usuario puede implementarse sobre un sistema operativo que no soporte threads. Todos los sistemas operativos tradicionales entran dentro de esta categora. Todas estas implementaciones tienen la misma estructura general, que se ilustra en la Figura 2-13(a). Los threads se ejecutan en lo alto de un sistema en tiempo de ejecucin (runtime system), que es una coleccin de procedimientos que gestiona los threads. Hemos visto cuatro de estos procedimientos anteriormente: thread_create, thread_exit, thread_wait y thread_yield, pero normalmente hay algunos procedimientos ms.

Figura 2-13. (a) Un paquete de threads a nivel de usuario. (b) Un paquete de threads gestionado por el ncleo. Cuando los threads se gestionan en el espacio del usuario, cada proceso necesita su propia tabla de threads privada para llevar el control de sus threads. La tabla de threads est gestionada por el sistema en tiempo de ejecucin. Cuando un thread pasa al estado preparado o bloqueado, la informacin necesaria para proseguir posteriormente con su ejecucin se guarda en la tabla de threads. Cuando un thread hace algo que puede provocar que se bloquee localmente entonces llama a un procedimiento del sistema en tiempo de ejecucin. Este procedimiento comprueba si el thread debe pasar al estado bloqueado. Si es as, el procedimiento guarda los registros del thread en la tabla de threads, busca en la tabla un thread preparado para ejecutarse, y recarga los registros de la mquina con los valores que se tienen guardados correspondientes al nuevo thread. Sin embargo existe una diferencia clave con respecto a los procesos. Cuando un thread termina de ejecutarse por el momento, por ejemplo cuando realiza una llamada a thread_yield, el cdigo de thread_yield puede salvar l mismo la informacin del thread en la tabla de

threads. Adems, puede llamar al thread planificador para que escoja otro thread para pasarlo a ejecucin. El procedimiento que salva el estado del thread y el planificador no son ms que procedimientos locales, por lo que su invocacin es mucho ms eficiente que realizar una llamada al ncleo. Entre otras cuestiones, no es necesario ningn trap, no es necesario ningn cambio de contexto, no es necesario vaciar la memoria cach, etc. Esto hace que la planificacin de los threads sea muy rpida. Los threads a nivel de usuario tienen tambin otras ventajas. Para empezar, permiten que cada proceso tenga su propio algoritmo de planificacin ajustado a sus necesidades. Para algunas aplicaciones, como por ejemplo aquellas con un thread recolector de basura, es una ventaja adicional el no tener que preocuparse sobre si un thread se ha quedado detenido en un momento inadecuado. Tambin se dimensionan mejor, ya que los threads a nivel del ncleo requieren invariablemente en el ncleo algn espacio para la tabla de threads y algn espacio de pila, lo que puede resultar un problema cuando el nmero de threads es muy grande. A pesar de su mayor eficiencia, los paquetes de threads a nivel de usuario tienen algunos serios problemas. El primero de ellos es el problema de cmo se implementan las llamadas al sistema bloqueantes. Supongamos que un thread lee desde el teclado antes de que se haya pulsado ninguna tecla. Es inaceptable permitir que el thread haga realmente esa llamada al sistema, ya que eso detendra a todos los threads del proceso. Uno de los principales motivos con que hemos justificado la necesidad de incorporar al sistema los threads fue el permitir utilizar llamadas bloqueantes pero sin que el bloqueo de un thread afectase a los dems. Con llamadas al sistema bloqueantes, es difcil imaginarse cmo puede conseguirse este objetivo fcilmente. Podemos modificar todas las llamadas al sistema para que no sean bloqueantes (por ejemplo haciendo que la llamada read sobre el teclado retorne inmediatamente 0 bytes si no hay caracteres en el bfer del teclado), pero exigir cambios sobre el sistema operativo es muy poco atractivo. Aparte de eso, uno de los argumentos para incorporar los threads a nivel de usuario fue precisamente que pudieran ejecutarse en los sistemas operativos existentes. Adicionalmente, cambiar la semntica de read requerira tambin realizar cambios en muchos de los programas de usuario ya escritos. Es posible otra alternativa en aquellos casos en los que es posible determinar con antelacin si una llamada al sistema va a producir un bloqueo. En algunas versiones de UNIX, existe una llamada al sistema, select, que permite al que la invoca saber si una determinada llamada read que se propone realizar va a bloquearse o no. Cuando se dispone de esta llamada, el procedimiento de librera read puede reemplazarse por uno nuevo que primero realiza una llamada a select y luego hace la llamada a read si es segura (es decir si no va a producir un bloqueo). Si por el contrario la llamada read va a producir un bloqueo, la llamada no se hace, y en su lugar se ejecuta otro thread. La siguiente vez que el sistema en tiempo de ejecucin tome el control, puede comprobar de nuevo si la llamada read es ya segura. Este enfoque requiere reescribir partes de la librera de llamadas al sistema, es ineficiente y nada elegante, pero no queda otra eleccin. El cdigo aadido alrededor de la llamada al sistema para hacer las comprobaciones sobre la seguridad de la llamada se denomina un jacket (chaqueta) o wrapper (envoltorio). Un problema anlogo al de las llamadas al sistema bloqueantes es el problema de las faltas de pgina. Estudiaremos ese problema en el captulo 4, pero de momento es suficiente con decir que los ordenadores pueden configurarse de forma que no todo el programa est en memoria principal a la vez. Si el programa llama o salta a una instruccin que no est en memoria, tiene lugar una falta de pgina y el sistema operativo debe ir y tomar las instrucciones

no encontradas (y sus vecinas) obtenindolas del disco. Eso es lo que se denomina una falta de pgina. El proceso se bloquea mientras se localizan y leen las instrucciones necesarias. Si un thread provoca una falta de pgina, el ncleo, que ni siquiera sabe de la existencia de los threads, bloquea en consecuencia al proceso entero hasta que la E/S del disco provocada por la falta de pgina se complete, y eso incluso aunque haya otros threads ejecutables dentro del proceso. Otro problema con los paquetes de threads a nivel de usuario es que si un thread comienza a ejecutarse, ningn otro thread en ese proceso podr volver a ejecutarse mientras que el primer thread no ceda voluntariamente la CPU. Dentro de un nico proceso, no existen interrupciones de reloj, lo que hace imposible planificar los threads de una forma tipo roundrobin (es decir turnndose peridicamente). A menos que un thread entre en el sistema en tiempo de ejecucin por su propia voluntad, el planificador nunca tiene la oportunidad de pasar a ejecucin a otro thread. Una posible solucin al problema de la ejecucin indefinidamente prolongada de los threads es hacer que el sistema en tiempo de ejecucin solicite una seal de reloj (interrupcin) una vez cada segundo para obtener el control, pero eso es tambin algo rudimentario y complicado de programar. Las interrupciones peridicas del reloj no siempre son posibles con una alta frecuencia, pero incluso aunque lo sean, generan una considerable sobrecarga total en el sistema. Adems, un thread tambin puede necesitar su propia interrupcin de reloj, la cual podra interferir con el uso que el sistema en tiempo de ejecucin estara ya haciendo del reloj. Otro, y probablemente el argumento ms demoledor en contra de a los threads a nivel de usuario es que, en general, los programadores desean utilizar los threads precisamente en las aplicaciones donde los threads se bloquean muy a menudo, como por ejemplo en un servidor web multihilo. Esos threads estn constantemente haciendo llamadas al sistema. Una vez que el thread ha hecho un trap al ncleo para llevar a cabo una llamada al sistema, no significa mucho ms trabajo para el ncleo conmutar a otro thread si el primero se bloquea, y dejar que el ncleo haga eso elimina la necesidad de hacer constantemente llamadas al sistema select para comprobar si las llamadas al sistema read son seguras. Para aplicaciones que esencialmente mantienen muy ocupada la CPU bloquendose raramente, cul es la ventaja de disponer de threads? Nadie puede proponer seriamente calcular los n primeros nmeros primos o jugar al ajedrez utilizando threads, debido a que no hay nada que ganar hacindolo de esa manera.

2.2.4 Implementacin de los Threads en el Ncleo

Ahora vamos a considerar el caso en el que el ncleo conoce y gestiona los threads. En ese caso, como se muestra en la Figura 2-13(b), no es necesario ningn sistema en tiempo de ejecucin dentro de cada proceso. Igualmente no existe ninguna tabla de threads en cada proceso. En vez de eso, el ncleo mantiene una tabla de threads que sigue la pista de todos los threads en el sistema. Cuando un thread desea crear un nuevo thread o destruir uno que ya existe, hace una llamada al ncleo, que es el que se encarga efectivamente de su creacin o destruccin actualizando la tabla de threads del sistema. La tabla de threads del ncleo guarda los registros de cada thread, su estado y otra informacin. La informacin es la misma que con threads a nivel de usuario, pero ahora esa informacin est en el ncleo en vez de en el espacio de usuario (dentro del sistema en tiempo de ejecucin). Esta informacin es un subconjunto de la informacin que los ncleos tradicionales mantienen sobre cada uno de sus procesos con un solo thread, esto es, el estado del proceso. Adicionalmente, el ncleo mantiene tambin la tabla de procesos para seguir la pista de los procesos. Todas las llamadas que puedan bloquear a un thread se implementan como llamadas al sistema, a un coste considerablemente ms alto que una llamada a un procedimiento del sistema

en tiempo de ejecucin. Cuando se bloquea un thread, el ncleo tiene la opcin de decidir si pasa a ejecutar otro thread del mismo proceso (si es que hay alguno preparado), o pasa a ejecutar un thread de un proceso diferente. Con threads a nivel de usuario el sistema en tiempo de ejecucin tiene que seguir ejecutando threads de su propio proceso hasta que el ncleo le arrebate la CPU (o hasta que no le queden threads preparados para ejecutarse). Debido al coste relativamente alto de crear y destruir los threads en el ncleo, algunos sistemas toman un enfoque medio-ambientalmente correcto reciclando sus threads. Cuando se destruye un thread, ste se marca como un thread no ejecutable, pero sin que se vean afectadas de otro modo sus estructuras de datos del ncleo. Posteriormente, cuando haya que crear un nuevo thread, se proceder a reactivar un antiguo thread marcado, ahorrando de esta manera algo de la sobrecarga de la creacin normal de un thread. Tambin es posible el reciclado de threads para threads a nivel de usuario, pero ya que la sobrecarga de la gestin de los threads es mucho menor, el incentivo para reciclar resulta menos atractivo. Los threads a nivel del ncleo no requieren ninguna llamada al sistema nueva de tipo no bloqueante. Adems, si un thread de un proceso provoca una falta de pgina, el ncleo puede comprobar fcilmente si el proceso tiene todava threads ejecutables, y en ese caso pasar a ejecutar uno de ellos mientras espera a que la pgina que provoc la falta se cargue desde el disco. Su principal desventaja es que el coste de una llamada al sistema es considerable, de manera que si las operaciones con threads (creacin, terminacin, etc.) son frecuentes, puede incurrirse en una elevada sobrecarga para el sistema.

5) Explique las diferencia entre bibliotecas

a) estticas b) dinmicas con carga en tiempo de carga. Para cada caso indique como se resuelve la bsqueda de las rutinas en Linux y Windows. Que diferencias hay entre las bibliotecas con carga en tiempo de loading y bibliotecas dinmicas con carga en tiempo de ejecucin?
Una librera esttica es una librera que "se copia" en nuestro programa cuando lo compilamos. Una vez que tenemos el ejecutable de nuestro programa, la librera no sirve para nada (es un decir, sirve para otros futuros proyectos). Podramos borrarla y nuestro programa

seguira funcionando, ya que tiene copia de todo lo que necesita. Slo se copia aquella parte de la librera que se necesite. Por ejemplo, si la librera tiene dos funciones y nuestro programa slo llama a una, slo se copia esa funcin.
Denominadas tambin libreras-objeto, son colecciones de ficheros objeto (compilados) agrupados en un solo fichero de extensin .lib, .a, etc. Durante la fase de enlazado, el linker incluye en el ejecutable los mdulos correspondientes a las funciones y clases de librera que hayan sido utilizadas en el programa, de forma que el conjunto entra a formar parte del ejecutable. Enlace dinmico significa que las subrutinas de una biblioteca son cargadas en un programa en tiempo de ejecucin y se mantienen como archivos independientes separados del fichero ejecutable del programa principal. El enlazador realiza una mnima cantidad de trabajo en tiempo de compilacin, registra que rutinas de la biblioteca necesita el programa y el ndice de nombres o nmeros de las rutinas en la biblioteca. La mayor parte de la labor de enlazado se realiza en el momento en que la aplicacin se carga (tiempo de carga o loadtime) o durante la ejecucin (tiempo de ejecucin o runtime). El necesario cdigo enlazado, llamado por el cargador, es de hecho parte del sistema operativo subyacente. En el momento adecuado el cargador localiza las bibliotecas en el disco y aade los datos relevantes de estas en el espacio de memoria del proceso. Algunos sistemas operativos slo pueden enlazar una biblioteca en tiempo de carga, antes de que el proceso comience su ejecucin, otros son capaces de esperar hasta despus de que el proceso haya empezado a ejecutarse y enlazar la biblioteca slo cuando efectivamente se hace referencia a ella (es decir, entiempo de ejecucin). Esto ltimo se denomina "retraso de carga". En cualquier caso, esa biblioteca es una biblioteca enlazada dinmicamente. Se deben calcular las direcciones cada vez que se carga el programa o la biblioteca.

Busqueda de libreras:
Estatica Linux: Al hacer uso de una librera, el compilador busca primero una versin dinmica (.so), si no la encuentra entonces busca la versin esttica. Si se tienen las dos versiones de una librera y se quiere utilizar la versin esttica debe indicarse al compilador el flag -static. gcc -static main.c util_uno.c util_dos.c util_tres.c -o prgestat

6..)Ejemplifique en un seudocdigo parecido a C como se usan las bibliotecas dinmica con enlace en tiempo de ejecucin. 6.a..)En seudocdigo muy simple indique como hace para llamar a una funcin de biblioteca func1( ) de la que no conoce el nombre de la biblioteca en que se encuentra hasta el momento de ejecucin.

7..) Cul es el problema de la relocacin que se debe resolver en las

bibliotecas dinmicas?. Como resuelve este problema la generacin de Position Independent Code/ Position Independent Executable ( PIC/PIE) ?
El problema es que se deben calcular las direcciones cada vez que se carga el programa o la biblioteca.
La principal caracterstica del cdigo PIC es que puede ejecutarse en cualquier posicin de memoria, de aqu que su uso principal sea formar el cdigo de bibliotecas compartidas de carga dinmica. El cdigo PIC accede a datos y funciones a travs de una tabla (Global Offset Table o GOT) que contiene sus direcciones de memoria, por tanto es un direccionamiento indirecto. Cuando se carga una biblioteca con cdigo PIC el GOT se modifica indicando las posiciones actuales en memoria de funciones y objetos/variables. Cuando se completa la carga el GOT contiene direcciones de memorias absolutas que indican la posicin de funciones y objetos, y un desplazamiento indicando la posicin dentro de la biblioteca. Para construir una biblioteca de este tipo se debe indicar al compilador que queremos este tipo de cdigo a traves de -fpic o -fPIC, la biblioteca no debe de tener cdigo ensamblador que sea dependiente de la posicin de memoria para su ejecucin. Adems la biblioteca no debe contener Text Relocations en su segmento de texto. Las Text Relocations son posiciones de memoria que aparecen en el cdigo de la biblioteca, si nuestra biblioteca contiene alguna de estas posiciones el cargador debera de corregirlas para apuntar a las posiciones actuales, con lo que se pierde rendimiento. Este retardo se puede minimizar usando prelink, cuya funcin es modificar estas posiciones en las bibliotecas y en los binarios, ahorrando calculos al cargador. Como hemos visto el cdigo PIC tiene muchas ventajas de cara al rendimiento general, Entonces por qu no podemos usar -fpic/-fPIC por defecto para todas las aplicaciones del sistema?: En ciertas arquitecturas como AMD64 realmente se podra hacer, ya que tolera muy bien el cdigo PIC y en algunos casos es hasta necesario en algunas arquitecturas. Sin embargo no es buena idea activarlo por defecto, es mejor activarlo cuando sea necesario dependiendo de la arquitectura en la que vayamos a compilar el cdigo y del propio cdigo. La razn es que los ejecutables se vuelven mas lentos.

La conclusin de todo esto es que siempre debemos usar cdigo PIC en bibliotecas de carga dinmica, mientras que no debemos hacerlo en los ejecutables.

8) > > Linkeo: > > > > Un programa prog01 llama a un procedimiento proc() Describir como son los > > mecanismos > > de link y de transferencia de control en ejecucin en el caso de: > > a) Enlace esttico > > b) Enlace dinmico resuelto en tiempo de link-edicin. > > c) Enlace dinmico resuelto en tiempo de ejecucin. > > Qu pasa en cada caso si proc() es compartida? > > > a) en enlace estatico el cdigo de proc() est integrado al archivo ejecutable (forma parte de dicho archivo) y se carga en memoria al cargarse el programa y convertirse en proceso. Si me llevo este archivo a otra maquina con el mismo sistema operativo, anda aunque las versiones de las libraries (bibliotecas) sean distintas. Se crea compilando con gcc -s (ver laboratorio) b) el procedimiento proc() se integra al ejecutable cuando se carga el programa a la memoria (o cuando se lo llama por priemra vez, depende del kernel y de la "ingenieria" de la biblioteca). Se sabe de que biblioteca (library) se carga porque en link-edicion se "resuelve" el nombre de la biblioteca. Para que funcione en otra maquina las versiones de las bibliotecas deben ser las mismas (o compatibles a nivel de llamada, en general las mas modernas son compatibles con las anteriores pero ...). c) En tiempo de ejecucion el programa "decide" de que biblioteca cargar y debe ubicar la biblioteca (dlopen() ) y el procedimiento dentro de la biblioteca (dlsym()). Ver detalle en el laboratorio donde hay un ejemplo de cada tipo. Si proc es compartido, en la version de carga dinamica con resolucion en link-edicion se usa la copia que esta en la memoria si hay alguna.

9..)Qu diferencias hay entre paravirtualizacin y los hipervisores tipo I y II? En Virtualizacin, cul es la diferencia entre paravirtualizacin y traduccin binaria?

La emulacin de hardware es la instalacin de software de virtualizacin (hipervisor, tambin llamado monitor de mquina virtual) antes de la instalacin de cualquier otro SO, este hipervisor presenta el hardware del computador a todos los sistemas operativos instalados emulando los recursos que este tiene. El hipervisor tambin coordina el acceso a los recursos del computador que se da por parte de los sistemas operativos instalados haciendo las veces de guarda de transito que decide quien va primero y quien tiene que esperar para usar los recursos. Los hipervisores se pueden
clasificar en dos tipos: Tipo 1 (nativo, baremetal o unhosted): software que se ejecuta directamente sobre el hardware real del equipo para controlar el hardware y monitorizar los sistemas operativos virtualizados. Los sistemas virtualizados se ejecutan en otro nivel por encima del hipervisor.

Algunos de los hipervisores tipo 1 ms conocidos son los siguientes: VMware: ESXi (gratis), ESX (de pago). Xen (libre). Citrix XenServer (gratis). Microsoft Hyper-V Server (gratis).

Tipo 2 (hosted): aplicacin que se ejecuta sobre un sistema operativo convencional (Linux, Windows, MacOS) para virtualizar sistemas. De esta forma la virtualizacin se produce en una capa ms alejada del hardware si lo comparamos con los hipervisores de tipo 1. Lgicamente esto hace que el rendimiento sea menor en los hipervisores de tipo 2.

Algunos de los hipervisores tipo 2 ms utilizados son los siguientes: Sun: VirtualBox (gratis), VirtualBox OSE (libre). VMware: Workstation (de pago), Server (gratis), Player (gratis). QEMU (libre). Micorsoft: Virtual PC, Virtual Server.

En la paravirtualizacion no se genera ninguna emulacin de hardware, por el contrario el hipervisor coordina el acceso de los sistemas operativos invitados a los recursos del computador fsico, los anfitriones interactan de manera directa con los recursos fsicos del computador como cuando se tiene un computador dedicado. Esta forma de virtualizar es mas bien una forma de compartir los recursos por tiempos cortos o a quien los necesite, dndole procesador o memoria o tarjeta de red al anfitrin que lo pide e intercalando el uso de estos entre los anfitriones.

Las instrucciones de la MV(Mquina Virtual) se ejecutan directamente en el procesador fsico, puesto que emplea sistemas operativos modificados para ello. La paravirtualizacin es una variante de la virtualizacin completa en la que el Hypervisor accede al sistema operativo directamente. Es decir, la mquina virtual enva las instrucciones al procesador directamente, sin necesidad de ser traducidas(permite un rendimiento igual a la ejecucin nativa).
Este sistema tiene varias ventajas, entre ellas la poca carga que le da al procesador al no tener que tener una capa completa de virtualizacin que se encarga de administrar los recursos y virtualizarlos. Otra de las ventajas, es que los sistemas invitados no tienen que limitarse a los accesorios de hardware que sean soportados por el hipervisor, pues al invitado actuar directamente con la parte fsica es posible manejar todos los accesorios que maneja el sistema operativo montado en el invitado. La desventaja es que para poder hacer esto, el hipervisor necesita modificar los sistemas operativos que se montan como invitados, es decir toma el cdigo del sistema operativo y le

agrega algunas lneas, as es como ya se puede imaginar solo sistemas operativos como Linux o BSD al cualquiera de cdigo abierto pueden ser usados. Windows no es una opcin en este caso. El software de paravirtualizacin mas conocido es Xen que se ofrece como software libre, este es desarrollado por una compaa llamada XenSource.

10.) Describa las condiciones de Popeck y Goldberg para virtualizar una plataforma. Discuta el caso de la virtualizacin de un Intel. Cumple el Intel Pentium con las condiciones de Popeck y Goldberg para virtualizar una plataforma?. Cmo se realiza esta virtualizacin?
P&G introdujeron una clasicacin de instrucciones en 3 grupos diferentes: -Instrucciones privilegiadas : aquellas a capturar si el procesador est en modo usuario y que no se capturan si est en modo privilegiado. -Instrucciones sensibles al control: aquellas que pretenden cambiar la conguracin de los recursos del sistema. -Instrucciones sensibles al comportamiento: aquellas cuyo comportamiento o resultado dependen de la conguracin de los recursos (contenido del registro de relocation o del modo del procesador). Estos dos ltimos conjuntos de instrucciones se agrupan como instrucciones sensibles (solo pueden ejecutarse en Modo Supervisor del procesado)y en trminos de virtualizacin son prcticamente igual de importante que las instrucciones privilegiadas a pesar de que no generen un cambio de modo del procesador. El resultado principal del anlisis de P&G se puede expresar a travs del siguiente teorema: Teorema : para cualquier computadora convencional de tercera generacin, el hipervisor de la mquina virtual(VMM) puede ser construido si el repertorio de instrucciones sensibles para esa computadora es un subrepertorio del repertorio de instrucciones privilegiadas. Intuitivamente, el teorema dice que para construir un VMM, es suciente que todas las instrucciones que pudiesen afectar al correcto funcionamiento del VMM (instruccin sensible) se capturen y pasen el control al VMM siempre. Esto garantiza el control de propiedad de los recursos. En cambio, las instrucciones no privilegiadas deben ejecutarse nativamente por eciencia. Intel Penditium no cumple ya que tiene instrucciones delicadas que no son privilegiadas. 11.) Es posible la virtualizacin de la arquitectura Intel 32 o 64 original?

Qu son los hardware assist tales como Pacifica (AMD-V) o Vanderpool (Intel IVT) y que hacen?

12.)Quien implementa el software de RAID (y donde se corre) y quien implementa el file system (el controlador o el Sistema Operativo) en? a) Un sistema con SAN b) Un sistema con NAS En cada caso haga un diagrama indicando que protocolo puede usarse en cada comunicacin. 13.)Describa la diferencia entre Storage Area Network y Network Area Storage (SAN y NAS). D ejemplo de los protocolos utilizados en cada caso.

NAS:
Este modo de almacenamiento se caracteriza por servir de soporte para el compartimiento de datos dentro de una red a travs del protocolo TCP-IP y basandose en sistemas de ficheros remotos como NFS (Network File System) o CIFS (Common Internet File System). Los equipos conectados a la NAS piden los datos (ficheros) de forma remota a la unidad NAS a travs de uno de estos dos protocolos y se almacenan en la propia mquina local.
NAS (del ingls Network Attached Storage) es el nombre dado a una tecnologa de almacenamiento dedicada a compartir la capacidad de almacenamiento de un computador (Servidor) con ordenadores personales o servidores clientes a travs de una red (normalmente TCP/IP), haciendo uso de un Sistema Operativo optimizado para dar acceso con los protocolos CIFS, NFS, FTP o TFTP. Generalmente, los sistemas NAS son dispositivos de almacenamiento especficos a los que se accede desde los equipos a travs de protocolos de red (normalmente TCP/IP). Tambin se podra considerar un sistema NAS a un servidor (Linux, Windows, ...) que comparte sus unidades por red, pero la definicin suele aplicarse a sistemas especficos. Los protocolos de comunicaciones NAS estn basados en ficheros por lo que el cliente solicita el fichero completo al servidor y lo maneja localmente, estn por ello orientados a informacin almacenada en ficheros de pequeo tamao y gran cantidad. Los protocolos usados son

protocolos de comparticin de ficheros como NFS o Microsoft Common Internet File System (CIFS). Muchos sistemas NAS cuentan con uno o ms dispositivos de almacenamiento para incrementar su capacidad total. Frecuentemente, estos dispositivos estn dispuestos en RAID (Redundant Arrays of Independent Disks) o contenedores de almacenamiento redundante. En la tecnologa NAS, las aplicaciones y programas de usuario hacen las peticiones de datos a los sistemas de ficheros de manera remota mediante protocolos CIFS y NFS, y el almacenamiento es local al sistema de ficheros. Sin embargo, DAS y SAN realizan las peticiones de datos directamente al sistema de ficheros.

SAN:
La principal diferencia entre una NAS y una SAN es que la SAN sirve los datos a bajo nivel a travs de protocolos SCSI con tecnologas como fibre channel o iSCSI. Los equipos conectados a la SAN no solicitan los ficheros sino que como estn conectados a bajo nivel solicitan el bloque concreto de un determinado disco. La mquina local conectada a una SAN ver el disco/comparticin de la SAN como si fuera un disco/sistema de archivos local en lugar de uno remoto.
Una red SAN se distingue de otros modos de almacenamiento en red por el modo de acceso a bajo nivel. El tipo de trfico en una SAN es muy similar al de losdiscos duros como ATA, SATA y SCSI. En otros mtodos de almacenamiento, (como SMB o NFS), el servidor solicita un determinado fichero, p.ej."/home/usuario/wikipedia". En una SAN el servidor solicita "el bloque 6000 del disco 4". La mayora de las SAN actuales usan el protocolo SCSI para acceder a los datos de la SAN, aunque no usen interfaces fsicas SCSI. Dos protocolos de red utilizados en una SAN son Fibre Channel e iSCSI. Una red de canal de fibra es muy rpida y no est agobiada por el trfico de la red LAN de la empresa. Sin embargo, es muy cara.

NAS vs SAN: NAS provides both storage and a file system. This is often contrasted with SAN (Storage Area Network), which provides only block-based storage and leaves file system concerns on the "client" side. SAN protocols are SCSI, Fibre Channel, iSCSI, ATA over Ethernet (AoE), orHyperSCSI. One way to loosely conceptualize the difference between a NAS and a SAN is that a NAS appears to the client OS (operating system) as a file server (the client can map network drives to shares on that server) whereas a disk available through a SAN still appears to the client OS as a disk, visible in disk and volume management utilities (along with client's local disks), and available to be formatted with a file system andmounted. Despite their differences, SAN and NAS are not mutually exclusive, and may be combined as a SAN-NAS hybrid, offering both file-level protocols (NAS) and block-level protocols (SAN) from the same system. An example of this is Openfiler, a free software product running on Linux-based systems.

14.)Explique los principios de funcionamiento de un RAID. En que se diferencian los raids de hard y los de software. Cual es el rol del file system en un sistema usando RAID?
RAID (array redundante de discos baratos <Redundant Array of Inexpensive Disks>) La idea bsica que hay tras el RAID es la de instalar una caja llena de discos junto a un ordenador (tpicamente un servidor grande), sustituir la tarjeta controladora de disco por una controladora RAID, copiar los datos al RAID y luego continuar con la operacin normal. En otras palabras, un RAID debe verse igual que un SLED (un nico disco grande y caro) a los ojos del sistema operativo, pero tiene un mayor rendimiento y una mayor fiabilidad. De esta manera, no se requieren cambios en el software para utilizar el RAID. Los RAID se presentan al software como un nico disco, pero adems, todos los RAID tienen la propiedad de que los datos se distribuyen entre las unidades de disco para permitir realizar operaciones en paralelo. Patterson y otros definieron varios esquemas diferentes para hacer esto, los cuales se conocen ahora como RAID nivel 0 hasta RAID nivel 5. Existen adems unos cuantos niveles ms que no trataremos. En la Figura 5-19(a) se ilustra el RAID nivel 0. En este caso el disco virtual simulado por el RAID se considera dividido en tiras (strips) de k sectores cada una, con los sectores de 0 a k 1 en la tira 0, los sectores de k a 2k 1 en la tira 1, y as de forma sucesiva. Para k = 1, cada tira es un nico sector; para k = 2, cada tira tiene dos sectores, etc. La organizacin RAID de nivel 0 escribe las tiras consecutivas repartindolas entre los discos por turno circular, como se muestra en la Figura 5-19(a) para un RAID con cuatro unidades de disco. Esta distribucin de los datos entre varias unidades de disco se denomina grabacin en tiras (striping). Por ejemplo, si el software enva un comando para leer un bloque de datos que consta de cuatro tiras consecutivas, comenzando al principio de una tira, el controlador RAID descompondr este comando en cuatro comandos, uno para cada uno de los cuatro discos, hacindolos operar en paralelo. Tenemos por tanto E/S paralela sin que el software sea consciente de ello. El RAID de nivel 0 funciona mejor si las peticiones son grandes; cuanto ms grandes, mejor. Si se pide un bloque mayor que el nmero de unidades de disco multiplicado por el tamao de la tira, algunas unidades recibirn mltiples peticiones de sectores, por lo que cuando terminen de atender la primera peticin, iniciarn la segunda. Corresponde al controlador descomponer la peticin inicial y enviar los comandos adecuados a los discos adecuados en el orden correcto, ensamblando luego correctamente los resultados en la memoria. El rendimiento es excelente y la implementacin es directa. El RAID de nivel 0 funciona peor con sistemas operativos que habitualmente piden datos un sector de cada vez. Los resultados son correctos, pero no hay ningn paralelismo y, por lo tanto, tampoco ninguna mejora del rendimiento. Otra desventaja de esta organizacin es que la fiabilidad es potencialmente peor que la de un SLED. Si un RAID consiste en cuatro discos, cada uno con un tiempo medio de fallo de 20.000 horas, fallar alguna unidad aproximadamente una vez cada 5000 horas perdindose irremisiblemente los datos. Un SLED con un tiempo medio de fallo de 20.000 horas sera cuatro veces ms fiable. Puesto que no hay redundancia en este diseo, en realidad no se trata de un verdadero RAID. La siguiente opcin, RAID de nivel 1, mostrada en la Figura 5-19(b), es ya un verdadero RAID. Todos los discos estn duplicados, de modo que hay cuatro discos primarios y cuatro de respaldo (backup). Al escribir, todas las tiras se escriben dos veces. Al leer, puede utilizarse cualquiera de las copias, distribuyendo la carga entre ms unidades de disco. Consecuentemente, el rendimiento de las escrituras no es mejor que con una sola unidad de disco, pero el rendimiento de las lecturas puede ser hasta dos veces mejor. La tolerancia a fallos es excelente: Si una unidad deja de funcionar, simplemente se utiliza la copia en su lugar. La

recuperacin consiste simplemente en instalar una nueva unidad de disco y copiar en ella la unidad de respaldo entera.

A ver, diferenciemos: RAID por software(En una capa entre el File System y el Device Driver): El procesador de la mquina es el que se ocupa de hacer todos los clculos, tomar todas las desiciones y determinar todos los eventos relacionados con el RAID. En el RAID por software tu vers DOS (o ms) discos, y t personalmente hars un RAID escogiendo particin a particin y unindolas en un RAID. Ventajas: Es muy barato, puesto que necesitars solamente los discos (con 2 basta para un raid-1). Si lo usars en un servidor con poco IO, entonces es el ideal. Desventajas: -Consumir recursos del procesador del servidor para mantener el raid. Aunque el autor de mdadm clama que no se consume casi, yo puedo dar fe de que he sufrido bastante por un servidor de mucho IO al que se me ocurri ponerle RAID por software. Cuando me cambi a RAID por hardware (en el mismo servidor) enseguida se not una mejora brutal (por decir un numero, quiz una mejora del 300%) -Necesitar particionar y unir las particiones en pedazos de raid (llamados md) -En caso de que falle un disco, tendr que reparticionar el disco daado en los pedazos adecuados y volver a unir cada uno de los md. RAID por hardware En este tipo de RAID, te vendern una tarjeta de RAID (0, 1, 5 1+0), la cual tu pondrs en la mquina, adems pondrs los discos necesarios en la mquina. Al arrancar la mquina, antes de cargar el bootloader, antes siquiera de instalar el sistema operativo, entrars a una consola de administracin del RAID, armars el RAID necesario o requerido y solo entonces proceders a instalar el sistema operativo. El sistema operativo ver UN slo disco.. que en realidad es la controladora de RAID por hardware hacindose pasar por un disco. En este tipo de RAID el sistema operativo no se enterar de que tiene un RAID debajo.. sencillamente leer y escribir al disco. Ventajas: -El sistema operativo, ni el procesador, gastarn recursos atendiendo al RAID, la tarjeta es la que atiende y hace todas las operaciones a los discos. -Es sumamente rpido, ya que no gasto recursos del procesador

-Es muy fcil de configurar, metes los discos, y configuras en la consolita de inicio.. despus te olvidas de reconfigurar. -En caso de falla de un disco, saco el disco daado y pongo el nuevo disco, la tarjeta hace el proceso de rplica Desventajas -Cuesta plata.

En mi opinin, es el rol del file system en un sistema usando RAID es el

mismo que en un sistema usando un nico disco duro.

15..) Qu papel cumple el Virtual File System?
Un sistema de archivos virtual (VFS) o conmutador de sistema de archivos virtual es una capa de abstraccin encima de un sistema de archivos ms concreto. El propsito de un VFS es permitir que las aplicaciones cliente tengan acceso a diversos tipos de sistemas de archivos concretos de una manera uniforme. Puede ser utilizada para tender un puente sobre las diferencias en los sistemas de archivos de Windows, de Mac OS y Unix, de modo que las aplicaciones pudieran tener acceso a archivos en los sistemas de archivos locales de esos tipos sin tener que saber a qu tipo de sistema de archivos estn teniendo acceso. Un VFS especifica un interfaz (o un contrato) entre el kernel y un sistema de archivos en concreto. Por lo tanto, es fcil agregar nuevos sistemas de archivos al kernel simplemente satisfaciendo el contrato. Los trminos del contrato pueden volverse incompatibles de una versin a otra, lo que requerira que sistemas de archivos concretos fuesen recompilados, y posiblemente modificados antes de la recompilacin, para permitirles trabajar con un nuevo lanzamiento del sistema operativo; o el proveedor del sistema operativo pueda realizar solamente cambios retrocompatibles al contrato, de modo que un sistema de archivos concreto construido para un lanzamiento dado del sistema operativo trabaje con las versiones futuras del mismo sistema operativo.

16)Como se realiza un write en un Log File System?

17)Que son los archivos mapeados a memoria? Cmo se acceden los archivos mapeados a memoria? Ejemplifique con un seudocdigo parecido a C. Cmo se acceden, leen y escriben los archivos mapeados a memoria? Ejemplifique con un seudocdigo parecido a C.
Un archivo proyectado en memoria (en ingls memory-mapped file, a veces traducido tambin como archivo mapeado en memoria o archivo de memoria mapeada) es, en informtica, una porcin de memoria virtual en la que se establece una correlacin directa byte a byte con una parte de un archivo o un recurso similar. Este recurso es, normalmente, un archivo presente en el disco duro, o bien un objeto de memoria compartida u otro tipo de recurso al que el sistema operativo puede referirse por medio del descriptor de archivo. Una vez disponible esta correlacin entre el archivo y el espacio de memoria, las aplicaciones pueden gestionar el acceso a ese recurso exactamente igual que si se tratara de memoria primaria.

Ejemplo lectura y escritura:

17..)Explique en un diagrama el funcionamiento de la tabla de pginas invertida .

18.) Explique en un diagrama con valores ejemplo el proceso de

traduccin y carga de pginas usando pginas invertida para una direccin a) cuyo mapeo se encuentra en la TLB. b) el mapeo no se encuentra en la TLB pero la pgina est en memoria c) la pgina no se encuentra en memoria.
Hace ya muchos aos que aparecieron los primeros programas demasiado grandes para caber en la memoria disponible. La solucin usualmente adoptada fue dividir el programa en trozos, llamados recubrimientos (overlays). El recubrimiento 0 era el que se ejecutaba primero. Cuando terminaba, llamaba a otro recubrimiento. Algunos sistemas de recubrimientos eran altamente complejos, permitiendo tener varios recubrimientos en memoria a la vez. Los recubrimientos se mantenan en el disco y el sistema operativo los intercambiaba entre el disco y la memoria, dinmicamente segn se iban necesitando. Aunque el sistema realizaba el trabajo real de intercambiar los recubrimientos, el programador tena que encargarse de dividir en trozos apropiados el programa. La tarea de dividir programas grandes en pequeos trozos modulares era laboriosa y tediosa, as que no pas mucho tiempo antes de que alguien idease una manera de dejar todo ese trabajo para el ordenador. El mtodo ideado (Fotheringham, 1961) se conoce ahora como memoria virtual. La

idea bsica detrs de la memoria virtual es que el tamao combinado del programa, sus datos y su pila pueden exceder la cantidad de memoria fsica disponible. El sistema operativo mantiene en la memoria principal aquellas partes del programa que se estn usando en cada momento, manteniendo el resto de las partes del programa en el disco. Por ejemplo, un programa de 16 MB puede ejecutarse sobre una mquina de 4 MB eligiendo cuidadosamente qu 4 MB se tendrn en la memoria en cada instante, e intercambiando partes del programa entre el disco y la memoria, segn sea necesario.

4.3.1 Paginacin
La mayora de los sistemas con memoria virtual utilizan una tcnica denominada paginacin, que vamos a describir ahora. En cualquier ordenador, existe un conjunto de direcciones de memoria que los programas pueden producir (la lgica la administra el SO). Cuando un programa utiliza una instruccin como MOV REG,1000 lo hace para copiar el contenido de la direccin de memoria 1000 en REG (o viceversa, dependiendo del ordenador). Las direcciones pueden generarse empleando indexacin, registros base, registros de segmento y otros mtodos. Estas direcciones generadas por el programa se denominan direcciones virtuales y constituyen el espacio de direcciones virtual. En ordenadores sin memoria virtual, la direccin virtual se coloca directamente sobre el bus de memoria y eso hace que la palabra de memoria fsica con esa direccin se lea o escriba. Cuando se utiliza memoria virtual, las direcciones virtuales no se envan directamente al bus de memoria, sino que van a una unidad de gestin de memoria (MMU; Memory Management Unit) que establece una correspondencia entre las direcciones virtuales y las direcciones fsicas de la memoria, como se ilustra en la Figura 4-9. El espacio de direcciones virtual se divide en unidades llamadas pginas. Las unidades correspondientes en la memoria fsica se denominan marcos de pgina. Las pginas y los marcos de pgina tienen siempre el mismo tamao, que en este ejemplo es de 4 KB, aunque en sistemas reales se han usado pginas desde 512 bytes hasta 64 KB. Con un espacio de direcciones virtual de 64 KB, y con una memoria fsica 32 KB, tenemos 16 pginas virtuales y 8 marcos de pgina. Las transferencias entre la RAM y el disco siempre se efectan en unidades de una pgina.

CASO a) Cuando el programa intenta acceder a la direccin 0, por ejemplo, con la instruccin MOV REG,0 la direccin virtual 0 se enva a la MMU. La MMU ve que esa direccin virtual cae en la pgina 0 (0 a 4095), que de acuerdo a su correspondencia est en el marco de pgina 2 (8192 a 12287). La MMU transforma entonces la direccin a 8192 y coloca la direccin 8192 en el bus. La memoria no tiene ningn conocimiento de la MMU y lo nico que ve es una peticin de lectura o escritura de la direccin 8192, que lleva a cabo. Por lo tanto, la MMU transforma efectivamente todas las direcciones virtuales entre 0 y 4095 en las direcciones fsicas entre 8192 y 12287. CASO c) Qu sucede si el programa intenta utilizar una pgina que no tiene correspondencia, por ejemplo, ejecutando la instruccin MOV REG,32780 que referencia el byte 12 dentro de la pgina virtual 8 (que comienza en 32768)? La MMU ve que la pgina no tiene correspondencia (lo que se indica con una cruz en la figura) y provoca una excepcin que hace que la CPU ceda el control al sistema operativo. Esta excepcin se denomina una falta de pgina. El sistema operativo escoge un marco de pgina poco utilizado y escribe su contenido de vuelta al disco. A continuacin el sistema operativo carga la pgina a la que se acaba de hacer referencia colocndola en el marco de pgina que acaba de quedar desocupado, modifica el mapa en la MMU y reinicia la instruccin interrumpida.

20..) Un Sistema con memoria virtual tiene un espacio de direcciones de

64KB (2^16). Los primeros 4 bits se usan para indicar el nmero de

pgina y el resto es el offset. La memoria instalada es la cuarta parte de su capacidad de direccionamiento. En un primer instante la memoria est segn la tabla: Frame Page Referenciada Dirty 0411 1A10 2200 3310 El sistema usa el algoritmo de paginado conocido como reloj o 2nd chance. El prximo frame a investigar es el 0 y antes que el reloj limpie los bits Referenciado y Dirty ocurren los siguientes accesos: A145 para escritura 5431 para lectura 716C para escritura Indicar como queda la tabla (y la memoria) despus de cada operacin, y si se porduce o no un page fault.
21) Un Sistema con memoria virtual tiene un espacio de direcciones de

64KB (2^16). Los primeros 4 bits se usan para indicar el nmero de pgina y el resto es el offset. La memoria instalada es la mitad de su capacidad de direccionamiento. En un momento determinado, la disposicin de la memoria es: Frame Pgina 03 1A 2C 34 40 5E 67 72 Dibuje las tablas de pginas correspondientes y explique con un diagrama como resuelve la direccin 0xC120 y la 0x1240 en el caso de: a) Una tabla de pginas nica. b) Una tabla de pginas invertida.
22)Qu son y cmo se manejan los servicios en Windows? Qu

componente del sistema los inicia?.

Los servicios no son nada mas ni nada menos que programas o aplicaciones cargadas por el propio sistema operativo. Estas aplicaciones tienen la particularidad que se encuentran corriendo en segundo plano (Background).

Los servicios son programas que se ejecutan con el sistema sin que el usuario los arranque. Estos servicios se arrancan (o no, dependiendo de su

configuracin) con el equipo y realizan las funciones para las que han sido desarrollados. Algunos de ellos son imprescindibles para que Windows arranque y/o funcione correctamente, pero la mayora ofrecen funciones adicionales (Wifi, Firewall, Servicios de Servidor, Compartir carpetas, etc), prescindibles dependiendo del uso del equipo. Cualquier programa puede convertirse en un servicio y muchos de los programas (antivirus, firewalls, etc) que instalamos en nuestro equipo se instalan como tales para estar siempre se arrancados funcionando como parte del sistema operativo. Para ver y administrar los servicios tenemos que usar la consola de administracin de servicios. Podemos acceder a ella desde el Administrador de equipos en Servicios y aplicaciones, o directamente ejecutando services.msc

23..) Describa en Windows el flujo de control que se lleva a cabo para una system call indicando el propsito de: a) subsystem DLL b) LPC c) Native System Services d) SubSystem Kernel Support

24)Describa el proceso de boot de Windows o de Linux hasta que se guarda la ltima configuracin que funciona (Windows) o hasta que se llega al runlevel especificado (Linux). (Slo describa uno de ellos)

25..) En Windows: Qu son los Subsistemas de Ambiente ( Envirnoment Subsystems) y las Bibliotecas dinmicas de Subsistemas (Subsystems DLL's)? Como se comunican entre si y con quien se comunican las aplicaciones?
El subsistema de ambiente expone un subconjunto de los servicios del executive a los programas de aplicacin. El Modo Kernel es un modo muy privilegiado de funcionamiento, donde el cdigo tiene el acceso directo a todo el hardware y toda la memoria, incluso a los espacios de direccin de todos los procesos del modo usuario. La parte de WINDOWS que corre en el modo Kernel se llama Ejecutor de Windows, que no es ms que un conjunto de servicios disponibles a todos los componentes del Sistema Operativo, donde cada grupo de servicios es manipulado por componentes que son totalmente independientes (entre ellos el Ncleo) entre s y se comunican a travs de interfaces bien definidas.
El modo usuario est formado por subsistemas que pueden pasar peticiones de E/S a los controladores apropiados del modo ncleo a travs del gestor de E/S (que se encuentra en el modo ncleo). Dos subsistemas forman la capa del modo usuario de Windows 2000: el subsistema de Entorno y el subsistema Integral. El subsistema de entorno fue diseado para ejecutar aplicaciones escritas para distintos tipos de sistemas operativos. Ninguno de los subsistemas de entorno puede acceder directamente al hardware, y deben solicitar el acceso a los recursos de memoria a travs del Gestor de Memoria Virtual que se ejecuta en modo ncleo. Adems, las aplicaciones se ejecutan a menor prioridad que los procesos del ncleo. Actualmente hay tres subsistemas de entorno principales: un subsistema Win32, un subsistema OS/2 y un subsistema POSIX.

SubSystem DLL Traduce las APIs documentadas en llamadas a las funciones nodocumentadas al sistema. Por ejemplo si una aplicacin Win32 se quiere comunicar con el subsistema Win32, llama una funcin desde la DLL apropiada, esta funcin usa la LPC(Servicios de Llamadas a Procedimientos Locales) para pasar la peticin al subsistema de procesos Win32, la que
procesa la demanda y realiza la accin pedida y devuelve un mensaje de realizacin a travs de la LPC.

26) En Windows Qu es el idle thread (o idle process o system

process)
(proceso inactivo de sistema). En sistemas operativos basados en Windows NT, el System Idle Process o Proceso inactivo de sistema, es un hilo de ejecucin del kernel que mide cunta capacidad de la CPU est sin uso en un determinado perodo de tiempo.

El proceso System Idle Process siempre se ejecuta de fondo en Windows NT, Windows XP y Vista y se encuentra bajo ese nombre o bajo el nombre de SYSTEM en el Administrador de Tareas de Windows. Es una tarea que no puede ser terminada. Por ejemplo, en general, si dice 95 en la columna CPU del Administrador de Archivos de Windows, significa que hay un 5% de la CPU que est en uso en ese instante y el restante sin uso. Esos ciclos de CPU sin uso son tomados por el System Idle Process. El System Idle Process es utilizado en Windows para ahorar energa del CPU. El ahorro de energa depende de las caractersticas del hardware y del firmware del sistema. Por ejemplo, en los procesadores x86, este proceso ejecutar un bcle de comandos HLT (un comando de lenguaje asembler), que causa que la CPU apague muchos componentes internos y espere hasta que arribe unIRQ. El System Idle Process mide la utilizacin del CPU en el sistema, lo cual puede ser visto a travs del Administrador de Tareas de Windows en la solapa Procesos. De todas maneras es ms fcil de entender desde la solapa Rendimiento (Performance) en la misma herramienta, donde se muestra grficamente el uso del CPU en todo momento, el uso histrico del CPU, entre otros datos. Hay que destacar, de todas maneras, que esa informacin que se muestra no es calculada a travs del System Idle Process, sino que se toma de contadores de rendimiento globales del sistema.