Drivers de Dispositivos

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.