Andrew s. Tanenbaum



Descargar 4,35 Mb.
Ver original pdf
Página134/134
Fecha de conversión12.11.2019
Tamaño4,35 Mb.
1   ...   126   127   128   129   130   131   132   133   134

HARD-

WARE

S

O

F

T

W

A

R

E

Figura 12-5.  La estructura de comunicación en Symbian OS tiene un conjunto exten-

so de características.



Módulos TSY La telefonía abarca una gran parte de la infraestructura de comunicaciones,

y se utilizan módulos especiales para implementarla. Los módulos del servidor de telefo-

nía (TSY) implementan la funcionalidad de telefonía. Los TSYs básicos pueden soportar

funciones telefónicas estándar (por ejemplo, hacer y terminar llamadas) en una amplia va-

riedad de hardware. Los TSYs más avanzados pueden soportar hardware telefónico avan-

zado, como los que soportan la funcionalidad GSM.



Módulos PRT Los módulos centrales que se utilizan para implementar protocolos son los

módulos de protocolos, o módulos PRT. Los servidores utilizan dichos módulos para im-

plementar protocolos. Un servidor crea una instancia de un módulo PRT cuando intenta

usar ese protocolo. Por ejemplo, la suite TCP/IP de protocolos se implementa mediante el

módulo TCPIP.PRT. Los protocolos de Bluetooth se implementan mediante el módulo

BT.PRT.


MTMs Como Symbian OS está diseñado de manera específica para la mensajería, los ar-

quitectos construyeron un mecanismo para manejar mensajes de todo tipo. Estos maneja-

dores de mensajes se conocen como módulos de tipos de mensajes, o MTMs. El manejo

de mensajes tiene muchos aspectos distintos, y los MTMs deben implementar cada uno de

estos aspectos. Los MTMs de interfaz de usuario deben implementar las diversas formas

en que los usuarios verán y manipularán mensajes, desde la forma en que un usuario lee

un mensaje, hasta la manera en que se le notifica sobre el progreso del envío de un men-

saje. Los MTMs del lado cliente manejan los procesos de dirigir, crear y responder a los

mensajes. Los MTMs del lado servidor deben implementar la manipulación orientada a

objetos de los mensajes, incluyendo la manipulación de carpetas y la manipulación espe-

cífica para los mensajes.

Estos módulos se basan en cada uno de los otros módulos de varias formas, dependiendo del

tipo de comunicación que se utilice. Por ejemplo, las implementaciones de los protocolos que uti-

lizan Bluetooth sólo utilizan módulos PRT encima de los drivers de dispositivo. Ciertos protocolos

IrDA hacen esto también. Las implementaciones de TCP/IP que utilizan PPP se basan en los módu-

los PRT, además de un módulo TSY y un módulo CSY. Las implementaciones de TCP/IP sin PPP

por lo general no utilizan un módulo TSY o un módulo CSY, pero sí vinculan un módulo PRT a un

driver de dispositivo de red.



Modularidad de la infraestructura

La modularidad de este modelo basado en pilas es útil para los implementadores. La calidad abs-

tracta del diseño en niveles debe ser evidente a través de los ejemplos que acabamos de mostrar.

Considere la implementación de la pila TCP/IP. Una conexión PPP puede ir directamente a un mó-

dulo CSY, elegir una implementación GSM o TSY de módem regular, que a su vez pasa por un

módulo CSY. Cuando el futuro traiga una nueva tecnología de telefonía, la estructura existente se-

guirá en funcionamiento y se requerirá sólo agregar un módulo TSY para la implementación de la

nueva telefonía. Además, para ajustar con detalle la pila del protocolo TCP/IP no se requiere alterar



956

CASO DE ESTUDIO 3: SYMBIAN OS

CAPÍTULO 12


SECCIÓN 12.9

RESUMEN


957

ninguno de los módulos de los que depende; simplemente se ajusta el módulo PRT de TCP/IP y se

deja el resto igual. Esta modularidad extensiva significa que el nuevo código se adhiere con facili-

dad a la infraestructura, el código antiguo se descarta con facilidad y el código existente se puede

modificar sin tener que trastornar todo el sistema o requerir reinstalaciones extensivas.

Por último, en la figura 12-5 se han agregado subcapas al nivel de aplicación. Hay módulos

CSY que las aplicaciones utilizan como interfaces para los módulos de protocolos en sus implemen-

taciones. Aunque podemos considerar estos módulos como partes de las implementaciones de pro-

tocolos, es un poco más conveniente considerarlas como aplicaciones asistentes. Aquí un ejemplo

podría ser una aplicación que utiliza IR para enviar mensajes SMS a través de un teléfono móvil.

Esta aplicación utilizaría un módulo CSY IRCOMM en el lado de aplicación, el cual utiliza una im-

plementación de SMS envuelta en un nivel de implementación de protocolos. De nuevo, la modu-

laridad de todo este proceso es una gran ventaja para las aplicaciones que se necesitan enfocar en

lo que hacen mejor, y no en el proceso de comunicaciones.



12.9  RESUMEN

Symbian OS se diseñó como un sistema operativo orientado a objetos para las plataformas de telé-

fonos inteligentes. Tiene un diseño de microkernel que utiliza un núcleo de nanokernel muy peque-

ño, e implementa sólo las funciones del kernel más rápidas y primitivas. Symbian OS emplea una

arquitectura cliente/servidor que coordina el acceso a los recursos del sistema con servidores en es-

pacio de usuario. Aunque está diseñado para teléfonos inteligentes, Symbian OS tiene muchas ca-

racterísticas de un sistema operativo de propósito general: procesos e hilos, administración de la

memoria, soporte para un sistema de archivos y una infraestructura de comunicaciones extensa.

Symbian OS implementa ciertas características únicas; por ejemplo, los objetos activos hacen mu-

cho más eficiente la espera de los eventos externos, la falta de memoria virtual hace más desafian-

te la administración de la memoria y el soporte a la orientación a objetos en los drivers de

dispositivos utiliza un diseño abstracto de dos capas.



PROBLEMAS

1. Para cada uno de los siguientes ejemplos de servicios, describa si se debe considerar una ope-

ración en espacio de kernel o en espacio de usuario (por ejemplo, en un servidor del sistema)

para un sistema operativo de microkernel como Symbian OS:

1. Programar un hilo para ejecutarlo

2. Imprimir un documento

3. Responder a una consulta de descubrimiento de Bluetooth

4. Administrar el acceso de un hilo a la pantalla

5. Reproducir un sonido cuando llegue un mensaje de texto

6. Interrumpir la ejecución para responder a una llamada telefónica


2. Haga una lista de tres mejoras en la eficiencia debido a un diseño de microkernel.

3. Haga una lista de tres problemas de eficiencia debido a un diseño de microkernel.

4. Symbian OS dividió el diseño de su kernel en dos niveles: el nanokernel y el kernel de Symbian

OS. Los servicios como la administración dinámica de la memoria se consideraban demasiado

complicados para el nanokernel. Describa los componentes complicados de la administración di-

námica de la memoria y por qué no podrían funcionar en un nanokernel.



5. Analizamos los objetos activos como una forma de mejorar la eficiencia del procesamiento de

la E/S. ¿Cree usted que una aplicación podría utilizar varios objetos activos al mismo tiempo?

¿Cómo reaccionaría el sistema cuando varios eventos de E/S requirieran acción?

6. ¿La seguridad en Symbian OS se enfoca en la instalación y en que Symbian firme las aplica-

ciones? ¿Podría haber un caso en el que una aplicación se colocara en almacenamiento para eje-

cutarla sin ser instalada? (Sugerencia: Piense en todos los posibles puntos de entrada de datos

para un teléfono móvil).



7. En Symbian OS, la protección de los recursos compartidos basada en servidor se utiliza en for-

ma extensa. Liste tres ventajas que tiene este tipo de coordinación de los recurso en el entorno

de microkernel. Haga sus conjeturas en cuanto a la forma en que cada una de sus ventajas po-

dría afectar a una arquitectura de kernel distinta.



958

CASO DE ESTUDIO 3: SYMBIAN OS

CAPÍTULO 12


13

DISEÑO DE SISTEMAS

OPERATIVOS

959

En los 12 capítulos anteriores tratamos muchos temas y analizamos gran cantidad de conceptos y

ejemplos relacionados con los sistemas operativos. El diseño de estos presenta características espe-

cíficas. En este capítulo daremos un vistazo rápido a algunas de las cuestiones y sacrificios que los

diseñadores de sistemas operativos deben considerar al diseñar e implementar un nuevo sistema.

Hay cierta cantidad de folclore sobre lo que es bueno y lo que es malo en las comunidades de los

sistemas operativos, pero es sorprendente que se haya escrito tan poco sobre ello. Tal vez el libro más

importante sea The Mythical Man Month (El mítico hombre-mes), una obra clásica de Fred Brooks en

la que relata sus experiencias en el diseño y la implementación del OS/360 de IBM. La edición del 20

aniversario revisa parte de ese material y agrega cuatro nuevos capítulos (Brooks, 1995).

Tres documentos clásicos sobre el diseño de sistemas operativos son “Hints for Computer Sys-

tem Design” (Lampson, 1984), “On Building Sistems That Hill Fail” (Corbató, 1991) y “End-to-

End Arguments in System Design” (Saltzer y colaboradores, 1984). Al igual que el libro de Brooks,

los tres documentos han sobrevivido el paso de los años extremadamente bien; la mayoría de sus

ideas siguen siendo tan válidas ahora como la primera vez que se publicaron.

Este capítulo se basa en estas fuentes y en la experiencia personal del autor como diseñador o

co-diseñador de tres sistemas: Amoeba (Tanenbaum y colaboradores, 1990), MINIX (Tanenbaum

y Woodhull, 1997) y Globe (Van Steel y colaboradores, 1999a). Como no existe un consenso en-

tre los diseñadores de sistemas operativos sobre la mejor forma de diseñar un sistema operativo,

este capítulo será por lo tanto más personal, especulativo y sin duda más controversial que los an-

teriores.


13.1  LA NATURALEZA DEL PROBLEMA DE DISEÑO

El diseño de sistemas operativos es más como un proyecto de ingeniería que una ciencia exacta. Es

mucho más difícil establecer objetivos claros y cumplirlos. Vamos a empezar con estos puntos.

13.1.1  Objetivos

Para poder diseñar un sistema operativo exitoso, los diseñadores deben tener una clara idea de lo que

quieren. La falta de un objetivo dificulta de manera considerable el proceso de tomar las decisiones

subsiguientes. Para aclarar más este punto, es instructivo dar un vistazo a dos lenguajes de progra-

mación: PL/I y C. IBM diseñó PL/I en la década de 1960, debido a que era una molestia dar sopor-

te tanto a FORTRAN como a COBOL, y era vergonzoso que los académicos empezaran a parlotear

en trasfondo que Algol era mejor que ambos. Por lo tanto, se estableció un comité para producir un

lenguaje que cumpliera con las necesidades de todas las personas: PL/I. Tenía un poco de FOR-

TRAN, un poco de COBOL y un poco de Algol. Fracasó debido a que carecía de una visión unifica-

dora. Era tan sólo una colección de características en guerra unas con otras, y demasiado voluminoso

como para poder compilarse con eficiencia, para iniciarse.

Ahora consideremos C. Este lenguaje fue diseñado por Dennis Ritchie con un propósito: la pro-

gramación de sistemas. Fue un enorme éxito, en gran parte debido a que Ritchie sabía lo que que-

ría y lo que no. Como resultado, se sigue utilizando de manera extensa más de tres décadas después

de su aparición. Tener una visión clara de lo que uno quiere es algo imprescindible.

¿Qué desean los diseñadores de sistemas operativos? Esto sin duda varía de un sistema a otro;

de los sistemas embebidos (incrustados) a los sistemas de servidor. Sin embargo, para los sistemas

operativos de propósito general hay que tener en cuenta cuatro puntos principales:

1. Definir las abstracciones.

2. Proveer operaciones primitivas.

3. Asegurar el aislamiento.

4. Administrar el hardware.

A continuación analizaremos cada uno de estos puntos.

La tarea más importante (y tal vez la más difícil) de un sistema operativo es definir las abstrac-

ciones correctas. Algunas de ellas, como los procesos, los espacios de direcciones y los archivos,

han estado presentes tanto tiempo que pueden parecer obvias. Otras, como los hilos, son más re-

cientes y, en consecuencia, menos maduras. Por ejemplo, si un proceso multihilo que tiene un hilo

bloqueado en espera de la entrada del teclado realiza una bifurcación, ¿hay un hilo en el nuevo pro-

ceso también en espera de la entrada del teclado? Otras abstracciones se relacionan con la sincro-

nización, las señales, el modelo de memoria, el modelado de la E/S y muchas otras áreas.



960

DISEÑO DE SISTEMAS OPERATIVOS

CAPÍTULO 13


SECCIÓN 13.1

LA NATURALEZA DEL PROBLEMA DE DISEÑO



961

Cada una de las abstracciones se puede instanciar en forma de estructuras de datos concretas.

Los usuarios pueden crear procesos, archivos, semáforos, etc. Las operaciones primitivas manipu-

lan estas estructuras de datos. Por ejemplo, los usuarios pueden leer y escribir archivos. Las opera-

ciones primitivas se implementan en la forma de llamadas al sistema. Desde el punto de vista del

usuario, el corazón del sistema operativo se forma mediante las abstracciones y las operaciones dis-

ponibles en ellas, a través de las llamadas al sistema.

Como varios usuarios pueden tener una sesión abierta en una computadora al mismo tiempo,

el sistema operativo necesita proveer mecanismos para mantenerlos separados. Un usuario no pue-

de interferir con otro. El concepto de proceso se utiliza ampliamente para agrupar recursos para 

fines de protección. Por lo general también se protegen los archivos y otras estructuras de datos.

Asegurar que cada usuario pueda realizar sólo operaciones autorizadas con datos autorizados es

un objetivo clave del diseño de sistemas. Sin embargo, los usuarios también desean compartir da-

tos y recursos, por lo que el aislamiento tiene que ser selectivo y controlado por el usuario. Esto

lo hace más difícil incluso. El programa de correo electrónico no debe ser capaz de hacer que fa-

lle el navegador Web. Incluso cuando sólo haya un usuario, los distintos procesos necesitan estar

aislados. 

La necesidad de aislar las fallas está muy relacionada con este punto. Si alguna parte del sis-

tema falla (lo más frecuente es un proceso de usuario), no se debe permitir que falle el resto del

sistema. El diseño debe asegurarse de que las diversas partes estén aisladas unas de otras. En teo-

ría, las partes del sistema operativo también se deben aislar unas de otras para permitir fallas in-

dependientes. 

Por último, el sistema operativo tiene que administrar el hardware. En especial tiene que cui-

dar todos los chips de bajo nivel, como los controladores de interrupciones y el bus. También tiene

que proporcionar un marco de trabajo para permitir que los drivers de dispositivos administren los

dispositivos de E/S más grandes, como los discos, las impresoras o la pantalla.



13.1.2  ¿Por qué es difícil diseñar un sistema operativo?

La Ley de Moore enuncia que el hardware de computadora mejora por un factor de 100 cada déca-

da, pero no hay ley alguna que declare el mejoramiento de los sistemas operativos en un factor de

100 cada diez años… o que siquiera mejoren. De hecho, se puede considerar que algunos de ellos

son peores, en ciertos sentidos clave (como la confiabilidad), que la versión 7 de UNIX, de la dé-

cada de 1970. 

¿Por qué? La mayor parte de las veces la inercia y el deseo de obtener compatibilidad inver-

sa tienen la culpa, y también el no poder adherirse a los buenos principios de diseño. Pero hay más

que eso. Los sistemas operativos son esencialmente distintos en ciertas formas de los pequeños

programas de aplicación que se venden en las tiendas por 49 (dólares). Vamos a ver ocho de las

cuestiones que hacen que sea mucho más difícil diseñar un sistema operativo que un programa de

aplicación.

En primer lugar, los sistemas operativos se han convertido en programas extremadamente 

extensos. Ninguna persona se puede sentar en una PC y escribir un sistema operativo serio en

unos cuantos meses. Todas las versiones actuales de UNIX sobrepasan los 3 millones de líneas de 


código. Windows Vista tiene más de 5 millones de líneas de código del kernel (y más de 70 millo-

nes de líneas de código en total). Nadie puede entender de 3 a 5 millones de líneas de código, mu-

cho menos 70 millones. Cuando tenemos un producto que ninguno de los diseñadores puede esperar

comprender por completo, no debe sorprender que los resultados estén con frecuencia muy aleja-

dos de lo óptimo.

Los sistemas operativos no son los más complejos de todos. Por ejemplo, las empresas de

transporte aéreo son mucho más complicadas, pero se pueden particionar en subsistemas aislados

para poder comprenderlos mejor. Las personas que diseñan los inodoros en una aeronave no tie-

nen que preocuparse por el sistema de radar. Los dos subsistemas no tienen mucha interacción. En

un sistema operativo, el sistema de archivos interactúa a menudo con el de memoria en formas

inesperadas e imprevistas.

En segundo lugar, los sistemas operativos tienen que lidiar con la concurrencia. Hay varios

usuarios y dispositivos de E/S activos al mismo tiempo. En esencia, es mucho más difícil adminis-

trar la concurrencia que una sola actividad secuencial. Las condiciones de carrera y los interblo-

queos son sólo dos de los problemas que surgen.

En tercer lugar, los sistemas operativos tienen que lidiar con usuarios potencialmente hostiles

que desean interferir con la operación del sistema o hacer cosas prohibidas, como robar los archi-

vos de otro usuario. EL sistema operativo necesita tomar las medidas necesarias para evitar que es-

tos usuarios se comporten de manera inapropiada. Los programas de procesamiento de palabras y

los editores de fotografías no tienen este problema. 

En cuarto lugar, a pesar del hecho de que no todos los usuarios desconfían de los otros, muchos

de ellos desean compartir parte de su información y recursos con otros usuarios seleccionados. El

sistema operativo tiene que hacer esto posible, pero de tal forma que los usuarios maliciosos no pue-

dan interferir. De nuevo, los programas de aplicaciones no se enfrentan a  ningún reto similar.

En quinto lugar, los sistemas operativos viven por mucho tiempo. UNIX ha estado en operación

durante un cuarto de siglo; Windows, durante más de dos décadas y no muestra signos de desapari-

ción. En consecuencia, los diseñadores tienen que pensar sobre la forma en que pueden cambiar el

hardware y las aplicaciones en un futuro distante, y cómo deben prepararse para ello. Por lo general,

los sistemas que están demasiado encerrados en una visión específica del mundo desaparecen.

En sexto lugar, los diseñadores de sistemas operativos en realidad no tienen una buena idea so-

bre la forma en que se utilizarán sus sistemas, por lo que necesitan proveer una generalidad consi-

derable. Ni UNIX ni Windows se diseñaron con el correo electrónico o los navegadores Web en

mente, y aun así hay muchas computadoras que utilizan estos sistemas operativos y casi todo el

tiempo utilizan estas dos aplicaciones. Nadie le dice a un diseñador de barcos cómo crear uno sin

especificarle que desean un bote de pesca, un crucero o un buque de guerra. E incluso algunos cam-

bian de opinión después de que les llega el producto. 

En séptimo lugar, por lo general los sistemas operativos modernos están diseñados para ser porta-

bles, lo cual significa que deben ejecutarse en varias plataformas de hardware. También tienen que ad-

mitir miles de dispositivos de E/S, y todos están diseñados de manera independiente, sin ningún tipo de

relación con los demás. Un ejemplo en donde esta diversidad ocasiona problemas es la necesidad 

de que un sistema operativo se ejecute en máquinas que utilizan las notaciones little-endian y big-en-

dian. Un segundo ejemplo se podía ver de manera constante en MS-DOS, cuando los usuarios trataban

de instalar, por ejemplo, una tarjeta de sonido y un módem que utilizaban los mismos puertos de E/S 

962

DISEÑO DE SISTEMAS OPERATIVOS

CAPÍTULO 13


SECCIÓN 13.2

DISEÑO DE INTERFACES



963

o las mismas líneas de petición de interrupción. Pocos programas además de los sistemas operativos

tienen que lidiar con los problemas que ocasionan las piezas de hardware en conflicto.

En octavo y último lugar, está la frecuente necesidad de tener compatibilidad inversa con cier-

to sistema operativo anterior. Ese sistema puede tener restricciones en cuanto a las longitudes de las

palabras, los nombres de archivos u otros aspectos que los diseñadores ya consideran obsoletos pe-

ro que deben seguir utilizando. Es como convertir una fábrica para producir los autos del próximo

año en vez de los de este año, pero seguir produciendo los autos de este año a toda su capacidad.



13.2  DISEÑO DE INTERFACES

Para estos momentos el lector debe tener claro que no es fácil escribir un sistema operativo moder-

no. Pero, ¿dónde se puede empezar? Tal vez el mejor lugar para iniciar sea pensar sobre las interfa-

ces que va a proporcionar. Un sistema operativo proporciona un conjunto de abstracciones, que en

su mayor parte se implementan mediante tipos de datos (por ejemplo, archivos) y las operaciones

que se realizan en ellos (por ejemplo, 

read

). En conjunto, estos dos elementos forman la interfaz



para sus usuarios. Hay que considerar que en este contexto, los usuarios del sistema operativo son

programadores que escriben código que utiliza llamadas al sistema, y no personas que ejecutan pro-

gramas de aplicación.

Además de la interfaz principal de llamadas al sistema, la mayoría de los sistemas operativos

tienen interfaces adicionales. Por ejemplo, algunos programadores necesitan escribir drivers de dis-

positivos para insertarlos en el sistema operativo. Estos drivers ven ciertas características y pueden

realizar llamadas a ciertos procedimientos. Estas características y llamadas también definen una in-

terfaz, pero es muy distinta de la que ven los programadores de aplicaciones. Todas estas interfaces

se deben diseñar con cuidado, para que el sistema tenga éxito.

13.2.1  Principios de guía

¿Acaso hay principios que puedan guiar el diseño de las interfaces? Nosotros creemos que sí. En

resumen son simplicidad, integridad y la habilidad de implementarse de manera eficiente.

Principio 1: Simplicidad

Una interfaz simple es más fácil de comprender e implementar sin que haya errores. Todos los di-

señadores de sistemas deben memorizar esta famosa cita del pionero francés aviador y escritor, An-

toine de St. Exupéry: 



No se llega a la perfección cuando ya no hay nada más que agregar, sino cuando ya no

hay nada que quitar.

Este principio dice que es mejor menos que más, por lo menos en el mismo sistema operativo.

Otra forma de decir esto es mediante el principio KISS: Keep It Simple, Stupid (Manténganlo bre-

ve y simple).



Principio 2: Integridad

Desde luego que la interfaz debe permitir al usuario hacer todo lo que necesita; es decir, debe estar

completa. Esto nos lleva a una famosa cita de Albert Einstein: 

Todo debe ser lo más simple posible, pero no más simple.

En otras palabras, el sistema operativo debe hacer exactamente lo que se necesita de él, y nada

más. Si los usuarios necesitan almacenar datos, debe proveer cierto mecanismo para almacenar-

los; si los usuarios necesitan comunicarse unos con otros, el sistema operativo tiene que propor-

cionar un mecanismo de comunicación. En su conferencia del Premio Turing de 1991, Francisco

Corbató, uno de los diseñadores de CTSS y MULTICS, combinó los conceptos de simplicidad e

integridad y dijo:

En primer lugar, es importante enfatizar el valor de la simplicidad y la elegancia, ya que

la complejidad tiende a agravar las dificultades y, como hemos visto, crear errores. Mi de-

finición de elegancia es la obtención de una funcionalidad dada con un mínimo de meca-

nismo y un máximo de claridad.

La idea clave aquí es mínimo de mecanismo. En otras palabras, cada característica, función y lla-

mada al sistema debe llevar su propio peso. Debe hacer una sola cosa y hacerla bien. Cuando un

miembro del equipo de diseño propone extender una llamada al sistema o agregar una nueva carac-

terística, los otros deben preguntar si ocurriría algo terrible en caso de que no se incluyera. Si la res-

puesta es: “No, pero alguien podría encontrar esta característica útil algún día” hay que ponerla en

una biblioteca de nivel de usuario y no en el sistema operativo, incluso si es más lenta de esa for-

ma. No todas las características tienen que ser más rápidas que una bala. El objetivo es preservar lo

que Corbató denominó un mínimo de mecanismo. 

Ahora consideremos en forma breve dos ejemplos de mi propia experiencia: MINIX (Tanen-

baum y Woodhull, 2006) y Amoeba (Tanenbaum y colaboradores, 1990). Para todos los fines y pro-

pósitos, MINIX tiene tres llamadas al sistema: 

send



receive



sendrec


. El sistema está estructurado

como una colección de procesos donde el administrador de memoria, el sistema de archivos y cada

driver de dispositivo son un proceso que se programa por separado. En primera instancia, todo lo

que el kernel hace es programar procesos y manejar el paso de mensajes entre ellos. En consecuen-

cia, se necesitan sólo dos llamadas al sistema: 

send


para enviar un mensaje y 

receive


para recibir-

lo. La tercera llamada (

sendrec

) es sólo una optimización por razones de eficiencia, para permitir



enviar un mensaje y devolver la respuesta con sólo una trampa en el kernel. Para realizar todo lo

demás se pide a algún otro proceso (por ejemplo, el proceso del sistema de archivos o el driver de

disco) que realice el trabajo. 

Amoeba es incluso más simple. Sólo tiene una llamada al sistema: realizar llamada a procedi-

miento remoto. Esta llamada envía un mensaje y espera una solicitud. En esencia es igual que 

sen-


drec

de MINIX. Todo lo demás está integrado en esta llamada.



964

DISEÑO DE SISTEMAS OPERATIVOS

CAPÍTULO 13


SECCIÓN 13.2

DISEÑO DE INTERFACES



965

Principo 3: Eficiencia

El tercer lineamiento es la eficiencia de la implementación. Si una característica o llamada al siste-

ma no se puede implementar con eficiencia, tal vez no valga la pena tenerla. También debe ser in-

tuitivamente obvia para el programador, en relación con el costo de una llamada al sistema. Por

ejemplo, los programadores de UNIX esperan que la llamada al sistema 

lseek


sea menos costosa

que la llamada al sistema 

read

, debido a que la primera sólo cambia un apuntador en la memoria,



mientras que la segunda realiza operaciones de E/S de disco. Si los costos intuitivos son incorrec-

tos, los programadores escribirán programas ineficientes.



13.2.2  Paradigmas

Una vez que se han establecido los objetivos, puede empezar el diseño. Un buen lugar para iniciar

es pensar sobre la forma en que los clientes verán el sistema. Una de las cuestiones más importan-

tes es cómo hacer que todas las características del sistema funcionen bien y presenten lo que se co-

noce comúnmente como coherencia arquitectónica. En este aspecto, es importante distinguir dos

tipos de “clientes” de los sistemas operativos. Por un lado están los usuarios, quienes interactúan

con los programas de aplicaciones; por el otro están los programadores, quienes escriben los siste-

mas operativos. Los primeros clientes tratan en su mayor parte con la GUI; los segundos tratan en

su mayor parte con la interfaz de llamadas al sistema. Si la intención es tener una sola GUI que do-

mine el sistema completo, como en la Macintosh, el diseño debe empezar ahí. Por otra parte, si la

intención es proporcionar todas las GUIs que sea posible, como en UNIX, la interfaz de llamadas

al sistema se debe diseñar primero. En esencia, realizar la primera GUI es un diseño de arriba ha-

cia abajo. Las cuestiones son qué características tendrá, la forma en que el usuario interactuará con

ella y cómo se debe diseñar el sistema para producirla. Por ejemplo, si la mayoría de los programas

muestran iconos en la pantalla que esperan a que el usuario haga clic en uno de ellos, esto sugiere

un modelo controlado por eventos para la GUI, y probablemente también para el sistema operati-

vo. Por otra parte, si la mayor parte de la pantalla está llena de ventanas de texto, entonces tal vez

sea mejor un modelo en el que los procesos lean del teclado.

Realizar la interfaz de llamadas al sistema primero es un diseño de abajo hacia arriba. Aquí las

cuestiones son qué tipo de características necesitan los programadores en general. En realidad no se

necesitan muchas características especiales para proporcionar una GUI. Por ejemplo, el sistema de

ventanas X de UNIX es sólo un programa grande en C que realiza llamadas a 

read



write



en el te-

clado, ratón y pantalla. X se desarrolló mucho después de UNIX y no se requirieron muchos cam-

bios en el sistema operativo para que funcionara. Esta experiencia validó el hecho de que UNIX

estaba bastante completo. 



Paradigmas de la interfaz de usuario

Para la interfaz a nivel de GUI y la interfaz de llamadas al sistema, el aspecto más importante es te-

ner un buen paradigma (a lo que algunas veces se le conoce como metáfora) para proveer una for-


ma de ver la interfaz. Muchas GUIs para los equipos de escritorio utilizan el paradigma WIMP que

vimos en el capítulo 5. Este paradigma utiliza apuntar y hacer clic, apuntar y hacer doble clic, arras-

trar y otros modismos más a lo largo de la interfaz para ofrecer una coherencia arquitectónica en to-

do el sistema. A menudo, estos son requerimientos adicionales para los programas, como tener una

barra de menús con ARCHIVO, EDICIÓN y otras entradas, cada una de las cuales tiene ciertos ele-

mentos de menú reconocidos. De esta forma, los usuarios que conocen un programa pueden apren-

der otro con rapidez.

Sin embargo, la interfaz de usuario WIMP no es la única posible. Algunas computadoras 

de bolsillo utilizan una interfaz de escritura manual estilizada. Los dispositivos multimedia dedi-

cados pueden utilizar una interfaz tipo VCR. Y por supuesto, la entrada de voz tiene un paradig-

ma completamente distinto. Lo importante no es tanto el paradigma que se seleccione, sino 

el hecho de que hay un solo paradigma que invalida a los demás y unifica a toda la interfaz de

usuario.

Sin importar el paradigma seleccionado, es importante que todos los programas de aplica-

ción lo utilicen. En consecuencia, los diseñadores de sistemas necesitan proveer bibliotecas y kits

de herramientas para que los desarrolladores de aplicaciones tengan acceso a los procedimientos

que producen la apariencia visual uniforme. El diseño de la interfaz de usuario es muy importan-

te, pero no es el tema de este libro, por lo que ahora regresaremos al tema de la interfaz del sis-

tema operativo.

Paradigmas de ejecución

La coherencia arquitectónica es importante a nivel de usuario, pero tiene igual importancia a ni-

vel de la interfaz de llamadas al sistema. Aquí es con frecuencia útil diferenciar entre el paradig-

ma de ejecución y el de datos, por lo que analizaremos ambos, empezando con el primero.

Hay dos paradigmas de ejecución de uso extenso: algorítmicos y controlados por eventos. El

paradigma algorítmico se basa en la idea de que se inicia un programa para realizar cierta función

que conoce de antemano, o que obtiene de sus parámetros. Esa función podría ser compilar un pro-

grama, realizar la nómina o volar un avión a San Francisco. La lógica básica está fija en el código,

y el programa realiza llamadas al sistema de vez en cuando para obtener datos de entrada del usua-

rio, servicios del sistema operativo, etc. Este método se describe en la figura 13-1(a).

El otro paradigma de ejecución es el paradigma controlado por eventos de la figura 13-1(b).

Aquí el programa realiza cierto tipo de inicialización; por ejemplo, al mostrar cierta pantalla y des-

pués esperar a que el sistema operativo le indique sobre el primer evento. A menudo este evento es

la pulsación de una tecla o un movimiento del ratón. Este diseño es útil para los programas muy in-

teractivos.

Cada una de estas formas de hacer las cosas engendra su propio estilo de programación. En el

paradigma algorítmico, los algoritmos son centrales y el sistema operativo se considera como pro-

veedor de servicios. En el paradigma controlado por eventos el sistema operativo también propor-

ciona servicios, pero este papel se ve eclipsado por su papel como coordinador de las actividades

de usuario y generador de los eventos consumidos por los procesos.

966

DISEÑO DE SISTEMAS OPERATIVOS

CAPÍTULO 13


SECCIÓN 13.2

DISEÑO DE INTERFACES



967

main( )


main( )

{

{



int ...;

mess_t msj;

init( );

init( );


hacer_algo( );

while (obtener_mensaje(&msj)) {

read(...);

switch (msj.type) {

hacer_algo_mas( );

case 1:...;

write(...);

case 2:...;

seguir_funcionando( );

case 3:...;

exit(0);

}

}



}

}

(a)



(b)

Figura 13-1.  (a) Código algorítmico.  (b) Código controlado por eventos.

Paradigmas de datos

El paradigma de ejecución no es el único que exporta el sistema operativo. El paradigma de datos

es igual de importante. La pregunta clave aquí es la forma en que se presentan las estructuras y los

dispositivos del sistema al programador. En los primeros sistemas de procesamiento por lotes de

FORTRAN, todo se modelaba como una cinta magnética secuencial. Las pilas de tarjetas que se

introducían se consideraban como cintas de entrada, las pilas de tarjetas que se iban a perforar 

se consideraban como cintas de salida, y la salida para la impresora se consideraba como una cin-

ta de salida. Los archivos en el disco también se consideraban como cintas. Para tener acceso alea-

torio a un archivo, había que rebobinar la cinta correspondiente al mismo y leerla de nuevo.

Para realizar la asignación se utilizaban tarjetas de control de trabajos de la siguiente manera:

MONTAR(CINTA08, CARRETE781)

EJECUTAR(ENTRADA, MISDATOS, SALIDA, PERFORADORA, CINTA08)

La primera tarjeta indicaba al operador que obtuviera el carrete 781 del estante de cintas y lo mon-

tara en la unidad de cinta 8; la segunda indicaba al sistema operativo que ejecutara el programa

FORTRAN que se acababa de compilar, y que asignara ENTRADA (el lector de tarjetas) a la cinta

lógica 1, el archivo de disco MISDATOS a la cinta lógica 2, la impresora (llamada SALIDA) a la cin-

ta lógica 3, la perforadora de tarjetas (llamada PERFORADORA) a la cinta lógica 4, y la unidad de

cinta física 8 a la cinta lógica 5.

FORTRAN tenía una sintaxis para leer y escribir en cintas lógicas. Al leer de la cinta lógica 1,

el programa obtenía la entrada de la tarjeta. Al escribir en la cinta lógica 3, la salida aparecería pos-

teriormente en la impresora. Al leer de la cinta lógica 5 se podía leer el carrete 781 y así en forma

sucesiva. Hay que tener en cuenta que la idea de la cinta era sólo un paradigma para integrar el lec-

tor de tarjetas, la impresora, la perforadora, los archivos de disco y las cintas. En este ejemplo, só-

lo la cinta lógica 5 era una cinta física; el resto eran archivos de disco ordinarios (en cola). Era un

paradigma primitivo, pero fue un inicio en la dirección correcta.


968

DISEÑO DE SISTEMAS OPERATIVOS

CAPÍTULO 13

Después llegó UNIX, que utiliza en forma más avanzada el modelo de “todo es un archivo”.

Mediante el uso de este paradigma, todos los dispositivos de E/S se consideran como archivos, y se

pueden abrir y manipular como archivos ordinarios. Las instrucciones de C

fd1 = open(“archivo1”, O_RDWR);

fd2 = open(“/dev/tty”, O_RDWR);

abren un verdadero archivo de disco y la terminal del usuario (teclado + pantalla). Las instruccio-

nes subsecuentes pueden utilizar fd1 fd2 para leer y escribir en ellos, respectivamente. De ahí en

adelante no hay diferencia entre acceder al archivo y a la terminal, excepto porque no se permite

realizar búsquedas en esta última.

UNIX no sólo unifica los archivos y los dispositivos de E/S, sino que también permite acceder

a otros procesos como archivos mediante las tuberías. Además, cuando se admiten archivos asigna-

dos, un proceso puede obtener su propia memoria virtual como si fuera un archivo. Por último, en

las versiones de UNIX que aceptan el sistema de archivos /proc, la instrucción de C

fd3 = open(“/proc/501”, O_RDWR);

permite al proceso (tratar de) acceder a la memoria del proceso 501 en modo de lectura y escritura

mediante el descriptor de archivo fd3, algo que puede ser útil para un depurador, por ejemplo.

Windows Vista va más allá y trata de hacer que todo parezca un objeto. Una vez que un proce-

so adquiere un manejador válido para un archivo, proceso, semáforo, bandeja de correo u otro ob-

jeto del kernel, puede realizar operaciones con él. Este paradigma es más general incluso que el de

UNIX y mucho más general que el de FORTRAN.

Los paradigmas unificadores ocurren también en otros contextos. Aquí vale la pena mencionar

uno de ellos: la Web. El paradigma detrás de la Web es que el ciberespacio está lleno de documen-

tos, cada uno de los cuales tiene un URL. Al escribir un URL o hacer clic en una entrada respalda-

da por un URL, el usuario recibe el documento. En realidad, muchos “documentos” no son

documentos en sí, sino que los genera un programa o una secuencia de comandos del shell cuando

llega una petición. Por ejemplo, cuando un usuario pide a una tienda en línea una lista de CDs de

un artista específico, un programa genera el documento al instante, pues no existía antes de realizar

la petición.

Ahora hemos visto cuatro casos: a saber, todo es una cinta, archivo, objeto o documento. En

los cuatro casos, la intención es unificar los datos, dispositivos y demás recursos para facilitar su

manejo. Cada sistema operativo debe tener un paradigma de datos unificador de ese tipo.



13.2.3  La interfaz de llamadas al sistema

Si uno cree en el dicho de Corbató del mecanismo mínimo, entonces el sistema operativo debe pro-

porcionar la menor cantidad de llamadas al sistema con las que pueda funcionar, y cada una debe

ser lo más simple posible (pero no más simple). Un paradigma de datos unificador puede desempe-

ñar un papel importante para ayudar con esto. Por ejemplo, si los archivos, procesos, dispositivos

de E/S y todo lo demás se ven como archivos u objetos, entonces se pueden leer mediante una 



SECCIÓN 13.2

DISEÑO DE INTERFACES



969

sola llamada al sistema 

read

. En caso contrario, tal vez sea necesario tener llamadas separadas pa-



ra 

read_file, read_proc

read_tty


, entre otras. 

En algunos casos puede parecer que las llamadas al sistema necesitan variantes, pero a menu-

do es mejor tener una sola llamada al sistema que maneje el caso general, con distintos procedi-

mientos de biblioteca para ocultar este hecho de los programadores. Por ejemplo, UNIX tiene una

llamada al sistema para superponer un espacio de direcciones virtuales de un proceso, 

exec


. La lla-

mada más general es

exec(nombre, argp, envp);

que carga el archivo ejecutable nombre y le proporciona argumentos a los que apunta argp y varia-

bles de entorno a las que apunta envp. Algunas veces es conveniente listar los argumentos en forma

explícita, para que la biblioteca contenga procedimientos que se llamen de la siguiente manera:

exec(nombre, arg0, arg1, …, argn, 0);

execle(nombre, arg0, arg1, …, argn, envp);

Todo lo que hacen estos procedimientos es poner los argumentos en un arreglo y después llamar a

exec


para que haga el trabajo. Este arreglo conjunta lo mejor de ambos mundos: una sola llamada

al sistema directa mantiene el sistema operativo simple, y a la vez el programador obtiene la con-

veniencia de varias formas de llamar a 

exec


.

Desde luego que tener una llamada para manejar todos los casos posibles puede salirse de con-

trol fácilmente. En UNIX, para crear un proceso se requieren dos llamadas: 

fork


seguida de 

exec


.

La primera no tiene parámetros; la segunda tiene tres. En contraste la llamada a la API Win32 para

crear un proceso (

CreateProcess

) tiene 10 parámetros, uno de los cuales es un apuntador a una es-

tructura con 18 parámetros adicionales.

Hace mucho tiempo, alguien debió haber preguntado si ocurriría algo terrible al omitir algunos

de estos parámetros. La respuesta sincera hubiera sido que en algunos casos, los programadores tal

vez tendrían que realizar más trabajo para lograr un efecto específico, pero el resultado neto hubie-

ra sido un sistema operativo más simple, pequeño y confiable. Desde luego que la persona con la

proposición de 10 + 18 parámetros podría haber respondido: “Pero a los usuarios les gustan todas

estas características”. La réplica podría haber sido que les gustan los sistemas que utilizan poca me-

moria y nunca tienen fallas. Los sacrificios entre obtener más funcionalidad a costa de más memo-

ria son por lo menos visibles, y se les puede asignar un precio (ya que se conoce el precio de la

memoria). Sin embargo, es difícil estimar las fallas adicionales por año que agregará cierta carac-

terística, y si los usuarios realizarían la misma decisión si conocieran el precio oculto. Este efecto

se puede resumir en la primera ley del software de Tanenbaum:

Al agregar más código se agregan más errores

Al agregar más características se agrega más código y consecuentemente más errores. Los progra-

madores que creen que al agregar nuevas características no se agregan nuevos errores son nuevos

en las computadoras, o creen que el hada de los dientes anda por ahí cuidándolos.



970

DISEÑO DE SISTEMAS OPERATIVOS

CAPÍTULO 13

La simplicidad no es la única cuestión que se debe considerar al diseñar las llamadas al siste-

ma. Una consideración importante es el eslogan de Lampson (1984):

No ocultes el poder.

Si el hardware tiene una forma en extremo eficiente de realizar algo, debe exponerse a los progra-

madores de manera simple y no enterrarse dentro de alguna otra abstracción. El propósito de las

abstracciones es ocultar las propiedades indeseables, no las deseables. Por ejemplo, suponga que el

hardware tiene una forma especial de desplazar mapas de bits extensos por la pantalla (es decir, la

RAM de video) a una alta velocidad. Se podría justificar el tener una nueva llamada al sistema pa-

ra acceder a este mecanismo, en vez de sólo proporcionar formas de leer la RAM de video y colo-

carla en memoria principal, y después volver a escribir todo de nuevo. La nueva llamada sólo

desplazaría bits y nada más. Si una llamada al sistema es rápida, los usuarios siempre pueden crear

interfaces más convenientes encima de ella. Si es lenta, nadie la utilizará.

Otra cuestión de diseño es la comparación entre las llamadas orientadas a conexión y aquéllas

orientadas a no conexión. Las llamadas al sistema estándar de UNIX y Win32 para leer un archivo

son orientadas a conexión, como utilizar el teléfono. Primero hay que abrir un archivo, después leer-

lo y por último cerrarlo. Algunos protocolos de acceso a archivos también son orientados a cone-

xión. Por ejemplo, para utilizar FTP el usuario primero debe iniciar sesión en la máquina remota,

luego leer los archivos y después cerrar la sesión.

Por otro lado, algunos protocolos de acceso a archivos remotos son orientados a no conexión.

Por ejemplo, el protocolo Web (HTTP) no tiene conexión. Para leer una página Web sólo hay que

pedirla; no se requiere configurar nada de antemano (se requiere una conexión TCP, pero esto es a

un nivel más bajo del protocolo; el protocolo HTTP para acceder a la Web en sí es orientada a no

conexión).

El sacrificio entre cualquier mecanismo orientado a conexión y uno orientado a no conexión es

el trabajo adicional que se requiere para establecer el mecanismo (por ejemplo, abrir el archivo) y

la ventaja de no tener que hacerlo en las llamadas subsiguientes (que tal vez sean muchas). Para la

E/S de archivos en una sola máquina, en donde el costo de configuración es bajo, tal vez la forma

estándar (primero abrir y después usar) sea la mejor. Para los sistemas de archivos remotos, se pue-

de hacer de ambas formas.

Otra cuestión relacionada con la interfaz de llamadas al sistema es su visibilidad. La lista de

llamadas al sistema requeridas por POSIX es fácil de encontrar. Todos los sistemas UNIX las ad-

miten, así como un pequeño número de llamadas adicionales, pero la lista completa siempre es pú-

blica. Por el contrario, Microsoft nunca ha hecho pública la lista de llamadas al sistema de Windows

Vista. En vez de ello se han hecho públicas la API Win32 y otras APIs, pero éstas contienen gran-

des cantidades de llamadas en las bibliotecas (más de 10,000) y sólo un pequeño número de ellas

son verdaderas llamadas al sistema. El argumento para hacer públicas todas las llamadas al sistema

es que permite a los programadores saber qué es económico (las funciones que se ejecutan en espa-

cio de usuario) y qué es costoso (las llamadas al kernel). El argumento para no hacerlas públicas es

que proporcionan a los implementadores la flexibilidad de cambiar las llamadas al sistema subya-

centes actuales para mejorarlas sin quebrantar los programas de usuario.



Document Outline

  • Sistemas Operativos Modernos
  • Contenido 
  • Prefacio 
  • Capítulo 1 Introducción 
  • Capítulo 2 Procesos e hilos 
  • Capítulo 3 Administración de memoria 
  • Capítulo 4 Sistemas de archivos 
  • Capítulo 5 Entrada/Salida 
  • Capíitulo 6 Interbloqueos 
  • Capítulo 7 Sistemas operativos multimedia 
  • Capítulo 8 Sistemas de múltiples procesadores 
  • Capítulo 9 Seguridad 
  • Capítulo 10 Caso de estudio 1: Linux 
  • Capítulo 11 Caso de estudio 2: Windows Vista 
  • Capítulo 12 Caso e estudio 3: SYMBIAN OS 
  • Capítulo 13 Diseño de Sistemas Operativos 
  • Capítulo 14 Lista de lecturas y bibliografía 
  • Indice 


Compartir con tus amigos:
1   ...   126   127   128   129   130   131   132   133   134


La base de datos está protegida por derechos de autor ©absta.info 2019
enviar mensaje

    Página principal