Sistemas operativos modernos

La sencillez no es el único aspecto que hay que cuidar al diseñar llamadas al sistema. Una consideración importante es el lema de Lampson (1984): No hay que ocultar la potencia. Si el hardware cuenta con un mecanismo muy eficiente para hacer algo, se debe exponer a la vista de los programadores de forma sencilla y no enterrarlo en alguna otra abstracción. El pro­ pósito de las abstracciones es ocultar propiedades indeseables, no ocultar las deseables. Por ejemplo, supongamos que el hardware tiene una forma especial de desplazar mapas de bits grandes por la pantalla (es decir, la RAM de vídeo) a alta velocidad. Se justificaría tener una nueva llamada al sistema para tener acceso a este mecanismo, en lugar de limitarse a ofrecer mecanismos para leer la RAM de vídeo, colocarla en la memoria principal y volver a escribir­ la. La nueva llamada debe limitarse a desplazar bits y no hacer nada más. Si una llamada al sis­ tema es rápida, los usuarios siempre podrán construir interfaces más cómodas con base en ella. Si es demasiado lenta, nadie la usará. Otra cuestión de diseño son las llamadas orientadas a conexiones en comparación con las llamadas sin conexiones. Las llamadas estándar para leer un archivo de UNIX y Win32 son orientadas a conexiones. Primero se abre un archivo, luego se lee y, por último, se cierra. Al­ gunos protocolos de acceso a archivos remotos también son orientados a conexiones. Por ejem­ plo, para usar FTP, el usuario primero inicia sesión en la máquina remota, lee los archivos y luego termina la sesión. Por otra parte, algunos protocolos de acceso a archivos remotos carecen de conexiones, co­ mo vimos en el capítulo 10. Cada llamada NFS es autónoma, así que los archivos no se abren an­ tes de leerse o escribirse. Y, por supuesto, tampoco tienen que cerrarse después. Web tampoco tiene conexiones: si se quiere leer una página Web, tan sólo se solicita; no se requiere una confí­ guración previa (sí se requiere una conexión TCP, pero está en un nivel más bajo del protocolo; en sí, el protocolo HTTP para acceso a Web es sin conexiones). Las ventajas y desventajas relativas de cualquier mecanismo orientado a conexiones y uno sin conexiones radican en el trabajo adicional que se requiere para establecer el mecanismo (por ejemplo, abrir el archivo) y la ganancia que se obtiene al no tener que hacerlo en llama­ das subsiguientes (que podrían ser muchas). En el caso de E/S de archivos en una sola máqui­ na, donde el costo de confíguración es bajo, quizá el mejor método sea el estándar (primero abrir, luego usar). En el caso de sistemas de archivos remotos, pueden presentarse argumentos en favor de ambos métodos. Otra cuestión relacionada con la interfaz de llamadas al sistema es su visibilidad. Es fácil hallar la lista de llamadas al sistema prescritas por POSIX. Todos los sistemas UNIX las reco­ nocen, además de unas cuantas llamadas adicionales, pero la lista completa siempre es pública. En contraste, Microsoft nunca ha hecho pública la lista de llamadas al sistema de Windows 2000. En vez de ello, se han hecho públicas la API Win32 y otras APIs, pero éstas contienen cantidades enormes de llamadas de biblioteca (más de 13,000 en el caso de Windows 2000), pe­ ro sólo unas cuantas son verdaderas llamadas al sistema. El argumento en favor de hacer públi­ cas todas las llamadas al sistema es que permite a los programadores saber qué es barato (funciones ejecutadas en espacio de usuario) y qué es costoso (llamadas al kernel). El argumen­ to en contra de hacerlas públicas es que esto proporciona a los implementadores flexibilidad pa­ ra cambiar las llamadas al sistema reales, mejorándolas sin inutilizar los programas de usuario.