Sistemas operativos modernos
12.3 IMPLEMENTACION Dejando a un lado las interfaces de usuario y de llamadas al sistema, examinemos ahora cómo puede impiementarse un sistema operativo. En las ocho secciones que siguen examinaremos algunas cuestiones conceptuales generales, relacionadas con estrategias de implementación. Después veremos algunas técnicas de bajo nivel que suelen ser útiles. 12.3.1 Estructura del sistema Tal vez la primera decisión que tengan que tomar los implementadores sea la relativa a la es tructura del sistema. Ya examinamos las principales posibilidades en la sección 1.7, pero las re pasaremos aquí. Un diseño monolítico no estructurado no es muy recomendable, excepto tal vez en el caso de un sistema operativo diminuto incorporado a, digamos, un refrigerador, pero incluso en esos casos sería debatible. Sistemas de capas Un método razonable que se ha establecido bien con el paso de los años es el sistema de ca pas. El sistema THE de Dijkstra (figura 1-25) fue el primer sistema operativo de capas. UNIX (figura 10-3) y Windows 2000 (figura 11-7) también tienen una estructura de capas, pero en ambos es más bien una forma de describir el sistema que un verdadero principio guía que se usó al construir el sistema. En el caso de un sistema nuevo, los diseñadores que decidan seguir esta ruta primero de berán escoger con mucho cuidado las capas y definir la funcionalidad de cada una. La capa in ferior siempre debe tratar de ocultar las peores peculiaridades del hardware, como hace HAL en la figura 11-7. La siguiente capa tal vez deba encargarse de las interrupciones, las conmu taciones de contexto y la MMU, así que por arriba de este nivel, el código es independiente de la máquina casi por completo. En la parte superior, los diferentes diseñadores tendrán disfintos gustos (y predisposiciones). Una posibilidad es que la capa 3 administre los subprocesos, in cluyendo la calendarización y la sincronización entre subprocesos, como se muestra en la figu ra 12-2. Lo que se busca aquí es que a partir de la capa 4 se tengan subprocesos correctos que se calendaricen en forma normal y se sincronicen empleando un mecanismo estándar (por ejemplo, mutexes). En la capa 4 podríamos hallar los controladores de disposifivos, cada uno ejecutándose co mo un subproceso individual con su propio estado, contador de programa, registros, etcétera, po siblemente (aunque no necesariamente) dentro del espacio de direcciones del kemel. Un diseño así puede simplificar de manera considerable la estructura de E/S porque cuando se presenta una interrupción, puede convertirse en una operación unlock con un mutex y una llamada al calen darizador para (tal vez) calendarizar el subproceso que ahora está listo y que estaba bloqueado en el mutex. MINIX adopta este método, pero en UNIX, Linux y Windows 2000 los maneja dores de interrupción se ejecutan en una especie de fierra de nadie, no como subprocesos pro piamente dichos que puedan calendarizarse, suspenderse, etc. Puesto que una buena parte de la
RkJQdWJsaXNoZXIy MjI4NDcx