con la gestión de archivos y con la E/S, como íoctl por ejemplo. En muchos casos, las aplicaciones no
acceden directamente a las llamadas del sistema, sino a utilidades que llaman al sistema en representación
del usuario. Las principales utilidades de este estilo son:
• Las bibliotecas de los lenguajes, como la libc.so de C, que traducen la petición del usuario a llamadas del sistema, convirtiendo los parámetros allí donde es necesario. Ejemplos de utilidades de biblioteca en C son fread, fwríte o printf. Las bibliotecas de enlace dinámico (DLL) de Windows. Por ejemplo, Kernel32 .dll incluye llamadas para la gestión de archivos y otros componentes de E/S.
• Los demonios del sistema, como los de red o los spooler de las impresoras. Son programas privilegiados que pueden acceder a recursos que las aplicaciones normales tienen vetados. Así, por ejemplo, cuando una aplicación quiere acceder al puerto de telnet, llama al demonio de red (inetd) y le pide este servicio. De igual forma, cuando se imprime un archivo, no se envía directamente a la impresora, sino que se envía a un proceso spooler que lo copia a unos determinados directorios y, posteriormente, lo imprime.
Esta forma de relación a través de representantes existe principalmente por razones de seguridad y de
control de acceso. Es fácil dejar que un proceso spooler, generalmente desarrollado por el fabricante del
sistema operativo y en el que se confía, acceda a la impresora de forma controlada, lo que evita problemas
de concurrencia, filtrando los accesos del resto de los usuarios.
La interfaz de E/S de las aplicaciones es la que define el modelo de E/S que ven los usuarios, por lo
que, cuando se diseña un sistema operativo, hay que tomar varias decisiones relativas a la funcionalidad que
se va a ofrecer al mundo exterior en las siguientes cuestiones:
• Nombres independientes de dispositivo.
• E/S bloqueante y no bloqueante.
• Control de acceso a dispositivos compartidos y dedicados.
• Indicaciones de error.
• Uso de estándares.
La elección de unas u otras características determina la visión del sistema de E/S del usuario.
A continuación, se estudian brevemente cada una de ellas.
Nombres independientes de dispositivo
Usar nombres independientes de dispositivo permite construir un árbol completo de nombres lógicos, sin
que el usuario vea en ningún momento los dispositivos a los que están asociados. La utilidad mount de
UNIX es un buen ejemplo de diseño. Si se monta el dispositivo /dev/hda3 sobre el directorio lógico /users,
a partir de ese instante todos los archivos del dispositivo se pueden acceder a través de /users, sin que el
nombre del dispositivo se vea en ningún momento. Es decir, que el archivo /dev/hda.3/pepe pasa a ser
/users/pepe después de la operación de montado.
Usar un árbol de nombres único complica la traducción de nombres, por lo que algunos sistemas
operativos, como Windows NT, no la incluyen. En Windows, cuando se accede a un dis positivo con un
nombre completo, siempre hay que escribir el nombre del dispositivo al que se accede (C:, D:, etc.). En las
últimas versiones se enmascaran los dispositivos con unidades de red, pero siempre hay que saber a cuál se
quiere acceder. Por ejemplo, Condor\users\profesores (Z:) identifica a una unidad de red que está en la
máquina Condor y que está montada en la computadora local sobre el dispositivo lógico z:. No hay en este
sistema un árbol de nombres único tan claramente identificado como en UNIX o LINUX.
E/S bloqueante y no bloqueante
La mayoría de los dispositivos de E/S son no bloqueantes, también llamados asíncronos, es decir, reciben la
operación, la programan, contestan e interrumpen al cabo de un cierto tiempo. Sólo los dispositivos muy
rápidos o algunos dedicados fuerzan la existencia de operaciones de E/S bloqueantes (también llamadas
síncronas). Sin embargo, la mayoría de las aplicaciones efectúan operaciones de E/S con lógica bloqueante,
lo que significa que emiten la operación y esperan hasta tener el resultado antes de continuar su ejecución.
En este tipo de operaciones, el sistema operativo recibe la operación y bloquea al proceso emisor hasta que
la operación de E/S ha terminado , momento en que desbloquea a la aplicación y le envía el estado del resultado de la opera ción. En este caso, la aplicación puede acceder a los datos inmediatamente, ya que los tiene disponi bles en la posición de memoria especificada, a no ser que hubiera un error de E/S.
Este modelo de programación es claro y sencillo, por lo que las principales llamadas al sistema de E/S.
como read o write en POSEX y ReadFile y WriteFile en Win32, bloquean al usuario y completan la
operación antes de devolver el control al usuario.
Las llamadas de E/S no bloqueantes se comportan de forma muy distinta, reflejando mejor Ja propia
naturaleza del comportamiento de los dispositivos de E/S. Estas llamadas permiten a la aplicación seguir su
ejecución, sin bloquearla, después de hacer una petición de E/S . El procesamiento de la
llamada de E/S consiste en recuperar los parámetros de la misma, asignar un identificador de operación de
E/S pendiente de ejecución y devolver a la aplicación este identificador. Las llamadas de POSIX aioread
aiowrite permiten realizar operaciones no bloqueantes. A continuación, el sistema operativo ejecuta la
operación de E/S en concurrencia con la aplicación, que sigue ejecutando su código. Es responsabilidad de la aplicación preguntar por el estado de la operación de E/S, usando una llamada al sistema especial para realizar esta consulta (alo walt), o cancelarla si ya no le interesa o tarda demasiado (aiocancel). En Windows se puede conseguir este mismo efecto indicando, cuando se crea el archivo, que se desea E/S no bloqueante (FILE_FLAG y usando las llamadas ReadFileEx y WriteFileEx.
Este modelo de programación es más complejo, pero se ajusta muy bien al modelo de algunos sistemas
que emiten peticiones y reciben la respuesta después de un cierto tiempo. Un programa que esté leyendo
datos de varios archivos, por ejemplo, puede usarlo para hacer lectura adelantada de datos y tener los datos
de un archivo listos en memoria en el momento de procesarlos. Un programa que escuche por varios
canales de comunicaciones podría usar también este modelo.
Es interesante resaltar que, independientemente del formato elegido por el usuario, el sistemaoperativo
procesa siempre las llamadas de E/S de forma no bloqueante, o asíncrona, para permitir la implementación
de sistemas de tiempo compartido.
Control de acceso a dispositivos
Una de las funciones más importantes de la interfaz de usuario es dar indicaciones de control de acceso a
los dispositivos e indicar cuáles son compartidos y cuáles dedicados. En general, las llamadas al sistema no
hacen este tipo de distinciones, que, sin embargo, son necesarias. Imagine qué ocurriría si dos archivos se
escribieran en la impresora sin ningún control. Ambos saldrían mezclados, siendo el resultado del trabajo
inútil.
Para tratar de resolver este problema se usan dos tipos de mecanismos:
• Mandatos externos (como el lpr para la impresora) o programas especiales (demonios) que se
encargan de imponer restricciones de acceso a los mismos cuando es necesario.
• Llamadas al sistema que permiten bloquear (lock) y desbloquear (unlock) el acceso a un dispositivo
o a parte de él. Usando estas llamadas, una aplicación se puede asegurar acceso exclusivo bloqueando el dispositivo antes de acceder y desbloqueándolo al terminar sus accesos. Para evitar problemas de bloqueos indefinidos, sólo se permiten bloqueos aconsejados (advisory), nunca obligatorios. Además, es habitual que el único usuario que puede bloquear un dispositivo de E/S como tal sea el administrador del sistema. Para el resto de usuarios, este privilegio se restringe a sus archivos.
La seguridad es un aspecto importante del control de accesos. No basta con que se resuelvan los conflictos de acceso. Hay que asegurar que el usuario que accede al sistema de E/S tiene de rechos de acceso suficientes para llevar a cabo las operaciones que solicita. En UNIX y LINUX, los aspectos de seguridad se gestionan en el gestor de archivos. En Windows NT existe un servidor de seguridad que controla los ccesos a los objetos.
Indicaciones de error
Las operaciones del sistema operativo pueden fallar debido a cuestiones diversas. Es importante decidir
cómo se va a indicar al usuario esos fallos.
En UNIX, por ejemplo, las llamadas al sistema que fallan devuelven —l y ponen en una variable global
errno el código de error. La descripción del error se puede ver en el archivo /usr/include/sys/errno.h o
imprimirlo en pantalla mediante la función perrorO. A continuación, se muestran algunos códigos de error
de UNIX junto con sus descripciones
#define EPERNM 1 /* Not super-user */
#define ENOENT 2 /* No such file or directory */
#define ESRCH 3 /* No such process */
#define EINTR 4 /* interrupted system cali */
#define ElO 5 /* I/O error */
#define ENXIO 6 /* No such device or address */
#define E2BIG 7 /*k Arg iist too long */
#define ENOEXEC 8 /* Exec format error */
#define EBAOF 9 /* Bad file number */
En Windows se devuelven más códigos de error en las llamadas a función, e incluso en algunos
parámetros de las mismas. Igualmente, se puede obtener más información del error mediante la función
GetLastError ().
Uso de estándares
Proporcionar una interfaz de usuario estándar garantiza a los programadores la portabilidad de sus
aplicaciones, así como un comportamiento totalmente predecible de las llamadas al sistema en cuanto a
definición de sus prototipos y sus resultados. Actualmente, el único estándar definido para la interfaz de
sistemas operativos es POSIX (Portable Operating Systeni interface) [ 19881, basado principalmente en la
interfaz del sistema operativo UNIX. Todos los sistemas operativos modernos proporcionan este estándar
en su interfaz, bien como interfaz básica (en el caso de UNIX y LINUX) o bien como un subsistema POSIX
(caso de Windows) que se ejecuta sobre la interfaz básica (Win32).
No hay comentarios:
Publicar un comentario