Sistemas operativos modernos

Si se cuenta con un equipo de trabajo numeroso, un enfoque alterno seria crear primero un diseño detallado de todo el sistema y luego asignar la escritura de diferentes módulos a distin­ tos grupos. Cada uno prueba su propio trabajo por separado. Una vez que están listos todos los componentes, se integran y prueban. El problema con este plan de ataque es que si nada fun­ ciona en un principio, podría ser difícil aislar los módulos que están fallando, o determinar si un grupo entendió mal lo que se suponía que iba a hacer otro módulo. No obstante, este méto­ do suele usarse en equipos de trabajo grandes, a fin de elevar al máximo el paralefismo de la labor de programación. 12.3.8 Técnicas útiles Ya hemos visto algunas ideas abstractas para diseñar e implementar sistemas. Ahora examina­ remos varias técnicas concretas que son útiles en la implementación de sistemas. Claro que hay muchas más, pero las limitaciones de espacio nos obligan a presentar sólo unas cuantas. Ocultación del hardware Una buena parte del hardware es fea. Es preciso ocultarla desde un principio (a menos que ex­ ponga potencia, cosa que no sucede muy a menudo). Algunos de los detalles de muy bajo ni­ vel pueden ocultarse con una capa tipo HAL como la de la figura 12-2. Sin embargo, muchos detalles de hardware no pueden ocultarse así. Algo que debe cuidarse desde un principio es la forma de manejar las interrupciones. És­ tas hacen desagradable la programación, pero los sistemas operafivos necesitan ocuparse de ellas. Un método consiste en convertirlas en otra cosa de inmediato. Por ejemplo, podría con­ vertirse al instante cada interrupción en un subproceso emergente. Así, a partir de ese punto se estarán manejando subprocesos, no interrupciones. Un segundo método consiste en convertir cada interrupción en una operación unlock para abrir un mutex que está esperando el controlador correspondiente. Entonces el único efecto de una interrupción será hacer que algún subproceso pase al estado fisto. Un tercer método sería convertir la interrupción en un mensaje para algún subproceso. El có­ digo de bajo nivel tan sólo elabora un mensaje que indica de dónde provino la interrupción, lo po­ ne en una cola e invoca al calendarizador para que (tal vez) ejecute el manejador, el cual quizá estaba bloqueado esperando el mensaje. Todas estas técnicas, y otras similares, ü-atan de conver­ tir las interrupciones en operaciones de sincronización de subprocesos. Hacer que cada interrup­ ción se maneje con un subproceso normal, en un contexto apropiado, es más fácil que ejecutar un manejador en el contexto arbitrario en el que se presentó la interrupción. Claro que esto debe ha­ cerse de forma eficiente, pero en las profundidades del sistema operativo todo debe ser eficiente. Casi todos los sistemas operativos se diseñan para que se ejecuten en múltiples plataformas de hardware. Esas plataformas pueden diferir en términos del chip de CPU, MMU, longitud de palabra, tamaño de RAM y otras características que no es fácil enmascarar con HÀL o su equi­ valente. No obstante, es muy deseable tener un solo conjunto de archivos fuente que se usen pa­ ra generar todas las versiones; de lo contrario, cada error de programación que aparezca tendrá que corregirse en múltiples archivos fuente, y hay peligro de que esos archivos comiencen a ser diferentes.