Sistemas operativos modernos

Por ejemplo, si todos los archivos, procesos, dispositivos de E/S y muchas cosas más se ven como archivos u objetos, todos podrán leerse con una sola llamada al sistema read. De lo con­ trario podría ser necesario tener llamadas al sistema individuales para leer archivos, leer pro­ cesos, leer terminales, etcétera. En algunos casos, podría parecer que las llamadas al sistema necesitan ciertas variantes, pero muchas veces es más recomendable tener una sola llamada al sistema que maneje el caso general, con diferentes procedimientos de biblioteca para ocultar ese hecho a los programado- res. Por ejemplo, UNIX tiene una llamada al sistema para superponer el espacio de direccio­ nes virtual de un proceso: exec. La llamada más general es exec(nombre, argp, envp); que carga el archivo ejecutable nombre y le proporciona los argumentos a los que apunta argp y las variables de entorno a las que apunta envp. A veces es conveniente enumerar los argumen­ tos en forma explícita, por lo que la biblioteca contiene procedimientos que se invocan así: execl(nombre, argO, arg1, ..., argn, 0); execle{nombre, argO, arg1 argn, envp); Lo único que hacen estos procedimientos es meter los argumentos en un arreglo e invocar a exec para que realice el trabajo. Este esquema ofrece lo mejor de ambos mundos: hay una so­ la llamada directa para que el sistema operativo sea sencillo, pero el programador cuenta con la comodidad de varias formas de invocar a exec. Desde luego, es fácil exagerar al tratar de tener una llamada que maneje todos los posibles casos. La creación de un proceso en UNIX requiere dos llamadas: fork seguida de exec. La primera no tiene parámetros; la segunda tiene tres. En contraste, la llamada de la API Win32 para crear un proceso, CreateProcess, tiene 10 parámetros, uno de los cuales es un apunta­ dor a una estructura que contiene otros 18 parámetros. Hace mucho tiempo, alguien debería haber hecho la pregunta: “¿Sucedería algo terrible si no incluyéramos todos estos parámetros?” La respuesta honesta habría sido: “En algunos casos, tal vez los programadores tendrían que trabajar un poco más para lograr cierto efecto, pero el resul­ tado neto sería un sistema operativo más sencillo, más pequeño y más confiable.” Desde luego, quien propuso la versión de 10+ 18 parámetros podría haber añadido: “Pero a los usuarios les gustan todas estas caracterísficas.” La répfica a eso podría haber sido: “Les gustan más los siste­ mas que ocupan poca memoria y nunca fallan.” Al menos el loma y daca entre más funcionali­ dad a expensas de más memoria es visible y se le puede poner un precio (ya que se conoce el precio de la memoria). Sin embargo, es difícil esfimar el número de fallas adicionales que causa­ rá alguna característica en un año, y si los usuarios tomarían la misma decisión si conocieran el precio oculto. Este efecto puede resumirse en la primera ley de software de Tanenbaum: Añadir más código añade más errores. Añadir más funciones añade más código y, por tanto, más errores. Los programadores que creen que la adición de nuevas funciones no añade nuevos errores son novatos en computación o creen que los protegerá un hada.