Sistemas operativos modernos

cesano especificar su tamaño con antelación. En el caso de subprogramas del kemel, el tamaño tiene que especificarse por adelantado, porque la pila ocupa cierto espacio de direcciones virtual del kemel y podría haber muchas pilas. La pregunta es: ¿cuánto espacio debe recibir cada una? Los equilibrios aquí son similares a los que deben considerarse en el caso de la tabla de procesos. Otro equilibrio de tipo estático frente a dinámico se da en la calendarización de procesos. En algunos sistemas, sobre todo los de tiempo real, la calendarización puede efectuarse en forma estática por adelantado. Por ejemplo, una aerolínea sabe a qué hora saldrán sus vuelos semanas antes de que partan. De forma similar, los sistemas multimedia saben con anticipación cuándo de­ berán calendarizar procesos de audio, vídeo y otros. En aplicaciones generales esto no es válido y la calendarización debe ser dinámica. Otra cuestión estática/dinámica es la estructura del kemel. Las cosas son mucho más sen­ cillas si el kemel se construye como un solo programa binario que se carga en la memoria pa­ ra ejecutarse. Sin embargo, la consecuencia de este diseño es que la adición de un nuevo dispositivo de E/S requiere que el kemel vuelva a enlazarse con el nuevo controlador de dispo­ sitivo. Las primeras versiones de UNIX funcionaban así, y era más que satisfactorio en un en­ tomo de minicomputadora en el que sólo se agregan nuevos dispositivos de E/S muy de vez en cuando. En la actualidad, casi todos los sistemas operativos permiten agregar código al kemel de forma dinámica, con toda la complejidad adicional que ello implica. 12.3.7 Implementación descendente o ascendente Aunque es mejor diseñar el sistema de forma descendente, en teoría puede impiementarse de forma descendente o ascendente. En una implementación descendente (top-down), los imple­ mentadores comienzan con los manejadores de llamadas al sistema y ven qué mecanismos y estructuras de datos se necesitan para emplearlos. Se escriben estos procedimientos y se con­ tinúa así hasta llegar al hardware. El problema con este método es que es difícil probar algo si sólo se cuenta con los proce­ dimientos de nivel más alto. Por ello, muchos implementadores consideran más práctico cons­ truir el sistema de manera ascendente (bottom-up). Este método implica primero escribir código para ocultar el hardware de nivel bajo, lo cual es en esencia la HAL de la figura 11-7. El mane­ jador de interrupciones y el controlador de reloj también se necesitan de inmediato. Luego puede atacarse el problema de la mulfiprogramación, junto con un calendarizador sencillo (por ejemplo, por tumo circular [round-robin]). A estas alturas ya deberá ser posible probar el sistema para ver si puede ejecutar múltiples procesos de forma correcta. Si funciona bien, habrá llegado el momento de definir con cuidado las diversas tablas y estmcturas de da­ tos que se necesitarán en todo el sistema, sobre todo, las que se usan para administrar procesos y subprocesos, y después la memoria. La E/S y el sistema de archivos pueden esperar en un principio, con la salvedad de un mecanismo primitivo para leer el teclado y escribir en la pan­ talla, a fin de poder efectuar pruebas y depuración. En algunos casos será preciso proteger las estructuras clave de datos de bajo nivel, permitiendo el acceso sólo por medio de procedimien­ tos específicos; esto es, en efecto, programación orientada a objetos, sea cual sea el lenguaje de programación empleado. Conforme se completan las capas inferiores, se pueden someter a pruebas exhaustivas. Así, el sistema avanza de manera ascendente, como en la construcción de edificios de oficinas.