Sistemas operativos modernos

Manejador de llamadas al sistema Sistema de archivos 1 Sistema de archivos m Memoria virtual Contro- lador 1 Contro- lador 2 Contro­ l a d a Subprocesos, calendarización y sincronización de subprocesos Manejo de interrupciones, conmutación de contexto, MMU Ocultar el hardware de bajo nivel Figura 12-2. Un posible diseño para un sistema operativo de capas moderno. complejidad de cualquier sistema operativo está en la E/S, vale la pena considerar cualquier técnica para hacerla más tratable y encapsulada. Arriba de la capa 4 esperaríamos hallar la memoria virtual, uno o más sistemas de archi­ vos y los manejadores de llamadas al sistema. Si la memoria virtual está en un nivel más bajo que los sistemas de archivos, el caché de bloques podrá paginarse a disco, permitiendo que sea el administrador de memoria virtual el que determine en forma dinámica cómo debe dividirse la memoria real entre páginas de usuario y páginas de kernel, incluyendo el caché. Windows 2000 funciona así. Exokernels Aunque la estructura de capas tiene partidarios entre los diseñadores de sistemas, también hay otra facción que adopta una perspectiva diametralmente opuesta (Engler et a i, 1995). Su punto de vista se basa en el argumento de exti^mo a extremo (Saltzer et a i, 1984). Este concepto di­ ce que si el programa de usuario tiene que hacer algo él mismo, es un desperdicio hacerlo tam­ bién en una capa más baja. Consideremos una aplicación de ese principio al acceso a archivos remotos. Si un sistema debe evitar que los datos se vayan a corromper en tránsito, entonces deberá cuidar que se calcu­ le la suma de verificación de cada archivo en el momento de escribirlo, guardándola junto con el archivo. Cuando un archivo se transfiere por una red desde el disco de origen hasta el proce­ so de desfino, la suma de verificación también se transfiere, y además se recalcula en el extre­ mo receptor. Si las dos sumas no coinciden, el archivo se desecha y se transfiere otra vez. Esta verificación es más exacta que el uso de un protocolo de red confiable, porque también atrapa errores de disco, errores de memoria, errores de software en los enrutadores y otros erro­ res además de los de transmisión de bits. El argumento de extremo a extremo dice que entonces no es necesario usar el protocolo de red confiable, pues el extremo (el proceso receptor) cuenta con suficiente información para verificar por sí solo la corrección del archivo. Desde este pun­ to de vista, la única razón para usar un protocolo de red confiable es la eficiencia, o sea, atrapar y reparar antes errores de transmisión. El argumento de extremo a extremo puede extenderse a casi todo el sistema operafivo, y favorece la idea de que el sistema operafivo no haga nada que el programa de usuario pueda