Sistemas operativos modernos

inactiva 90% del tiempo. Si un sistema operativo basado en microkemel convirtiera un sistema de 900 MHz poco confiable en un sistema de 800 MHz confiable, lo más probable es que po­ cos usuarios se quejarían. A fin de cuentas, casi todos ellos estaban muy contentos hace algunos años cuando obtuvieron su computadora anterior que operaba a la entonces vertiginosa veloci­ dad de 100 MHz. Sistemas extensibles En los sistemas cliente-servidor que acabamos de ver, lo que se buscaba era aprovechar el ker­ nel al máximo. El enfoque opuesto consiste en colocar más módulos en el kernel, pero de for­ ma protegida. La palabra clave aquí es protegida, claro. En la sección 9.5.6 estudiamos algunos mecanismos de protección que en un principio se habían diseñado para importar applets (sub- programas) por Internet, pero eran igual de aplicables a la inserción de código ajeno en el ker­ nel. Los más importantes son las cajas de arena y el firmado de código, pues la interpretación no resulta muy prácfica en el caso de código del kemel. Desde luego, un sistema extensible por sí solo no es una forma de estructurar un sistema operafivo. No obstante, si se parte de un sistema mínimo que consiste en poco más que un me­ canismo de protección y se añaden al kemel módulos protegidos, uno por uno, hasta lograr la funcionalidad deseada, puede construirse un sistema mínimo para la apHcación en cuestión. Con este método, un sistema operativo nuevo puede adecuarse a cada aplicación, incluyendo sólo las partes que requiere. Paramecium es un ejemplo de este tipo de sistemas (Van Doom, 2001). Subprocesos de kemel Otra cuestión pertinente aquí es la de los subprocesos de sistema, sea cual sea el modelo de es­ tructuración escogido. A veces conviene permitir la existencia de subprocesos de kemel, indepen­ dientes de cualquier proceso de usuario. Estos subprocesos pueden ejecutarse en segundo plano, escribiendo páginas sucias en el disco, intercambiando procesos entre la memoria principal y el disco, etc. De hecho, el kemel mismo puede estructurarse por completo con tales subprocesos, para que cuando un usuario emita una llamada al sistema, en vez de que el subproceso del usua­ rio se ejecute en modo de kemel, ese subproceso se bloquee y transfiera el control a un subpro­ ceso de kemel que efectúe el trabajo. Además de subprocesos de kernel que se ejecutan en segundo plano, casi todos los siste­ mas operativos inician también muchos procesos demonio en segundo plano. Aunque éstos no forman parte del sistema operativo, suelen realizar actividades de tipo “sistema”, que podrían incluir recibir y enviar correo electrónico y atender diversos tipos de solicitudes de usuarios re­ motos, como FTP y páginas Web. 12.3.2 Mecanismo en comparación con políticas Otro principio que ayuda a la coherencia arquitectónica, además de que evita que las cosas crez­ can demasiado y las mantiene bien estructuradas, es el de separar el mecanismo y las políticas. Al colocar el mecanismo en el sistema operativo y dejar la política a los procesos de usuario, e!