Al principio de este capítulo analizamos lo que hacen los drivers. Vimos
que cada controlador tiene
ciertos registros de dispositivos que se utilizan para darle comandos o
ciertos registros de dispositivos
que se utilizan para leer su estado, o ambos. El número de registros de
dispositivos y la
naturaleza de los comandos varían radicalmente de un dispositivo a otro.
Por ejemplo, un driver de
ratón tiene que aceptar información del ratón que le indica qué tanto se
ha desplazado y cuáles botones
están oprimidos en un momento dado. Por el contrario, un driver de disco
tal vez tenga que
saber todo acerca de los sectores, pistas, cilindros, cabezas,
movimiento del brazo, los propulsores
del motor, los tiempos de asentamiento de las cabezas y todos los demás
mecanismos para hacer
que el disco funcione en forma apropiada. Obviamente, estos drivers
serán muy distintos.
Como consecuencia, cada dispositivo de E/S conectado a una computadora
necesita cierto código
específico para controlarlo. Este código, conocido como driver,
es escrito por el fabricante del
dispositivo y se incluye junto con el mismo. Como cada sistema operativo
necesita sus propios drivers,
los fabricantes de dispositivos por lo común los proporcionan para
varios sistemas operativos
populares.
Cada driver maneja un tipo de dispositivo o, a lo más, una clase de
dispositivos estrechamente
relacionados. Por ejemplo, un driver de disco SCSI puede manejar por lo
general varios discos
SCSI de distintos tamaños y velocidades, y tal vez un CD-ROM SCSI
también. Por otro lado, un
ratón y una palanca de mandos son tan distintos que por lo general se
requieren controladores diferentes.
Sin embargo, no hay una restricción técnica en cuanto a que un driver
controle varios dispositivos
no relacionados. Simplemente no es una buena idea.
Para poder utilizar el hardware del dispositivo (es decir, los registros
del controlador físico), el
driver por lo general tiene que formar parte del kernel del sistema
operativo, cuando menos en las
arquitecturas actuales. En realidad es posible construir controladores
que se ejecuten en el espacio
de usuario, con llamadas al sistema para leer y escribir en los
registros del dispositivo. Este diseño
aísla al kernel de los controladores, y a un controlador de otro,
eliminando una fuente importante
de fallas en el sistema: controladores con errores que interfieren con
el kernel de una manera u otra.
Para construir sistemas altamente confiables, ésta es, en definitiva, la
mejor manera de hacerlo. Un
ejemplo de un sistema donde los controladores de dispositivos se
ejecutan como procesos de usuario
es MINIX 3. Sin embargo, como la mayoría de los demás sistemas
operativos de escritorio esperan
que los controladores se ejecuten en el kernel, éste es el modelo que
consideraremos aquí.
Como los diseñadores de cada sistema operativo saben qué piezas de
código (drivers) escritas
por terceros se instalarán en él, necesita tener una arquitectura que
permita dicha instalación. Esto
implica tener un modelo bien definido de lo que hace un driver y la
forma en que interactúa con el
resto del sistema operativo.
