Sistemas operativos modernos

sistema en sí no tiene que modificarse, aunque haya necesidad de cambiar la política. Incluso si el módulo de políticas fiene que mantenerse en el kernel, se debe aislar del mecanismo, si es po­ sible, para que los cambios en el módulo de políticas no afecten al módulo de mecanismo. Para hacer más clara la división entre políficas y mecanismo, consideremos dos ejemplos del mundo real. Pensemos en una empresa grande que fiene un departamento de nómina encar­ gado de pagar los salarios de los empleados. Este departamento fiene computadoras, software, cheques en blanco, convenios con bancos y otros mecanismos para pagar en verdad los sala­ rios. En cambio, la política —determinar cuánto se paga a cada quién— es completamente aparte y la decide la gerencia. El departamento de nómina sólo obedece órdenes. Como segundo ejemplo, consideremos un restaurante: fiene el mecanismo para servir co­ midas, que incluye mesas, platos, meseros, una cocina llena de equipo, convenios con compa­ ñías de tarjetas de crédito, etc. Las políficas las establece el chef, a saber, lo que está en el menií. Si el chef decide que el tofu ha pasado de moda y los filetes gruesos son lo que está al día, el mecanismo existente podrá manejar esta nueva polífica. Consideremos ahora algunos ejemplos de sistemas operativos. Primero, pensemos en la ca­ lendarización de subprocesos. El kemel podría tener un calendarizador por prioridad, con k ni­ veles de prioridad. El mecanismo es un arreglo, indizado por nivel de prioridad, como se muestra en la figura 10-11 o en la figura 11-19. Cada entrada es la cabeza de una lista de sub­ procesos listos que fienen un mismo nivel de prioridad. El calendarizador simplemente explora el arreglo desde la prioridad más alta hasta la más baja, seleccionando los primeros subprocesos que encuentre. La política consiste en establecer las prioridades. Por ejemplo, el sistema podría tener diferentes clases de usuarios, cada uno con diferente prioridad. También podría permitir a los procesos de usuario establecer la prioridad relativa de sus subprocesos. Las prioridades po­ drían elevarse después de terminar una operación de E/S o reducirse después de consumir un cuanto. Hay muchas otras políticas que podrían adoptarse, pero la idea aquí es la separación en­ tre establecer la política y ponerla en práctica. Un segundo ejemplo es la paginación. El mecanismo implica administración de la MMU, mantener listas de páginas ocupadas y páginas libres, y código para transferir páginas entre la memoria y el disco. La polífica consiste en decidir qué hacer cuando se presenta un fallo de pá­ gina, que podría ser local o global, basada en LRU o en FIFO, o en otra cosa, pero este algo­ ritmo puede (y debe) ser completamente independiente del mecanismo real de administración de las páginas. Un tercer ejemplo es permitir la carga de módulos en el kernel. El mecanismo tiene que ver con la forma en que se insertan, cómo se enlazan, qué llamadas pueden efectuar y cuáles se les pueden hacer. La polífica consiste en determinar a quién se permite cargar qué módulos en el kernel. Tal vez sólo el superusuario pueda cargar módulos, pero quizá cualquier usuario puede cargar un módulo que haya sido firmado en forma digital por la autoridad apropiada. 12.3.3 Ortogonalidad Un buen diseño de sistema comprende conceptos individuales que pueden combinarse de for­ ma independiente. Por ejemplo, en C hay fipos de datos primitivos que incluyen enteros, ca­ racteres y números de punto flotante. También hay mecanismos para combinar tipos de datos,