Sistemas operativos modernos

hacer por su cuenta. Por ejemplo, ¿para qué tener un sistema de archivos? Basta con dejar que el usuario lea y escriba una porción del disco puro de forma protegida. Claro que a la mayoría de los usuarios le gusta tener archivos, pero el argumento de extremo a extremo dice que el sis­ tema de archivos debe ser un procedimiento de biblioteca enlazado con cualquier programa que necesite usar archivos. Este método permite a diferentes programas tener sistemas de archivos distintos. Esta línea de razonamiento dice que lo único que debe hacer el sistema operativo es asignar recursos de forma segura (por ejemplo, la CPU y los discos) a los usuarios que compi­ ten entre sí. El exokernel es un sistema operativo construido de acuerdo con el argumento de extremo a extremo (Engler etal., 1995). Sistemas cliente-servidor Un término medio entre hacer que el sistema operativo se encargue de todo o que no haga na­ da, es que el sistema operativo haga un poquito. Este diseño lleva a un microkemel, con una buena parte del sistema operativo ejecutándose como procesos servidores en el nivel de usua­ rio, como se ilustra en la figura 1-27. Éste es el diseño más modular y flexible de todos. Lo fundamental en flexibilidad es que cada controlador de dispositivo se ejecute también como proceso de usuario, protegido en forma plena contra el kernel y otros controladores. Sacar los controladores de dispositivos del kernel eliminaría la fuente más grande de inestabilidad en cualquier sistema operativo —controladores plagados de errores, escritos por terceros— y se­ ría un gran avance en cuanto a confiabiUdad. Desde luego, los controladores de dispositivos necesitan acceso a los registros de disposi­ tivos en hardware, así que se requiere algún mecanismo para hacerlo. Si el hardware lo permi­ te, cada proceso controlador podría tener acceso sólo a los dispositivos de E/S que necesita. Por ejemplo, con E/S con correspondencia en memoria, cada proceso controlador podría tener una correspondencia con la página de su dispositivo, pero ninguna otra página de dispositivo. Si el espacio de puertos de E/S puede protegerse de manera parcial, podría proporcionarse la por­ ción correcta de ese espacio a cada controlador. Incluso si no se cuenta con ayuda del hardware, puede lograrse que la idea funcione. Lo que se necesita entonces es una nueva llamada al sistema, disponible sólo para procesos con­ troladores de dispositivos, que proporcione una lista de pares (puerto, valor). Lo que el kernel hace es verificar primero si el proceso posee todos los puertos de la fista. De ser así, copia los valores correspondientes en los puertos, para iniciar la E/S con los dispositivos. Puede ufilizar- se una llamada similar para leer los puertos de E/S de forma protegida. Este método evita que los controladores de dispositivos examinen (y dañen) estructuras de datos del kemel, lo cual es bueno (por lo general). Podría proporcionarse un conjunto análogo de llamadas que permitan a los procesos controladores leer y escribir tablas del kemel, pero só­ lo de forma controlada y con la aprobación del kernel. El problema principal con este método, y con los microkernels en general, es la merma en el desempeño causada por todas las conmutaciones de contexto adicionales. Sin embargo, ca­ si lodos los trabajos sobre microkernels se efectuaron hace muchos años, cuando las CPUs eran mucho más lentas. En la actualidad no hay muchas aplicaciones que expriman hasta la última gota de capacidad de la CPU y no puedan tolerar una pequeña baja en el desempeño. Después de todo, cuando se ejecuta un procesador de texto o un navegador Web, tal vez la CPU está