dispositivo y niveles de soporte del controlador

DISPOSITIVO Y NIVELES DE SOPORTE DEL CONTROLADOR
Controlador
Controlador
Plug and Play
Plug and Play
NO
Dispositivo PnP
Full Plug and Play
NO hay Plug and Play
Dispositivo NO PnP
Posible PnP Parcial
NO hay Plug and Play
Tal y como vemos en la tabla anterior. Cualquier dispositivos que soporte Plug and
Play debe tener un controlador (driver) Plug and Play. La lista que damos a
continuación, explica las posibles configuraciones:
Dispositivo y controlador Plug and Play. Soporte a Plug and Play completo (full).
Esta es la configuración optima al soporte Plug and Play, la implementación en el
hardware debe cumplir con la iniciativa de diseño OnNow, incluyendo ACPI.
Únicamente en placas madre y BIOS que sean ACPI.
Dispositivo Plug and Play y controlador no Plug and Play – SIN soporte Plug and
Play en este caso. Sí el controlador no soporta Plug and Play, es dispositivo se
comportará como un dispositivo NO PnP. Esta situación influirá negativamente en
las capacidades de TODO el sistema.
Dispositivo NO Plug and Play y controlador Plug and Play. Posible soporte parcial al
Plug and Play. Un dispositivo NO Plug and Play puede tener un soporte parcial Plug
and Play. Sin embargo no es posible para el sistema el reconocimiento automático y
dinámico del hardware y la carga de los controladores apropiados, es posible tener
un manejo y asignación de recursos mediante una interface para interactuar con el
controlador y en sistema Plug and Play, interactuar con la Administración de Enegía
y registrar los sucesos de notificación del dispositivo. Tambien, si un dispositivo NO
Plug and Play tiene un controlador Plug and Play el dispositivo aparecerá
correctamente en el Administrador de Dispositivos y sus propiedades estarán
igualmente disponibles.
Dispositivo NO Plug and Play y controlador NO Plug and Play. No existe soporte
Plug and Play en este caso. Los controladores de dispositivos ‘legados’ escritos
antes de que el soporte Plug and Play fuese incorporado al sistema operativo
continuarán funcionando tal y como lo hacían anteriormente (sin ninguna capacidad
Plug and Play). Todos los nuevos controladores deben soportar Plug and Play.
COMPONENTES DEL PLUG AND PLAY
Class
Installers
Setup
Plug and Play Manager
Enumeration
Control
Spooler
Control Panel
Applets
Hardware Event
Mangement
Aplicaciones
Modo User
Modo Kernel
I/O Manager
Plug and Play
Manager
Executive
I/O Interface
Power Manager
PnP Interface
Power Manager Interface
Otras Interfaces
WDM Interface
WDM Plug and Play BUS Drivers
PCI
USB
PC Card
ACPI
1394
Otros
componentes
WDM
Device
Drivers
Windows NT
Device
Drivers
HAL (Hardware Abstraction Layer)
Administrador de Plug and Play en modo-kernel
El administrador de Plug and Play en modo kernel mantiene el control central
permitiendo a los controladores de bus la enumeración y la configuración y
permitiendo a los controladores de dispositivo añadir un dispositivo, arrancarlo y
utilizarlo.
Por ejemplo, el administrador de Plug and Play puede enviar peticiones para
determinar cuando un dispositivo puede ser parado o quitado a salvo. El
administrador de Plug and Play coordina con el modo-user de Plug and Play la
pausa o el quitar los dispositivos que estén disponibles para estas acciones.
Administrador de políticas y Administrador de Energía.
El Administrador de Energía es el componente en modo kernel que trabaja en
combinación con el Administrador de Políticas para manejar las APIs del
Administrador de Energía. Coordinando sucesos de energía y generando IRPs para
dicha administración. Por ejemplo, cuando varios dispositivos solicitan ser
apagados, el Administrador de Energía colecciona dichas peticiones. Determina que
peticiones deben ser serializadas
administración de esta energía.
y
genera
las
correspondientes
IRPs
de
El Administrador de Políticas vigila la actividad en el sistema e integra el estado de
usuario, el estado de aplicación y el estado del controlador de dispositivos en la
Política de Energía. Bajo determinadas circunstancias o bajo petición, el
Administrador de Políticas genera IRPs para cambiar el estado del dispositivo de
Energía.
Administrador de Entrada / Salida (I/O Manager).
El Administrador de E/S da los servicios de núcleo para los controladores de
dispositivos. El Administrador de E/S es el componente en modo kernel que
translada las paticiones de lectura y escritura en modo ‘user’ en IRPs de lectura y
escritura. Este maneja todas las IRPs del sistema operativo. Esta interface trabaja
de la misma forma en que lo hacía en NT 4. Debe notarse que ambos, Windows NT
4 y Windows 2000 incluyen en el Administrador de E/S un controlador de Plug and
Play que podía ser instalado manualmente en Windows NT 4.
Interface WDM para Plug and Play.

Desde la perspectiva de Plug and Play hay tres tipos de controladores
(drivers)
o
o
o

Controladores de BUS
Controladores de ‘Función’
Controladores de ‘Filtro’
Interfaces adicionales en Windows 2000
o
o
Los controladores de Plug and Play de Windows 2000 no están
limitados a usar interfaces WDM.
Los controladores pueden llamar a otras interfaces para soportar
controladores ‘legados’ de Windows 2000.
El sistema de Entrada / Salida (E/S) nos suministra una arquitectura de capas para
los controladores. Vamos a introducir los tipos de controloadores de WDM, capas de
drivers y objetos sobre los dispositivos.
Tipos de controladores
Desde la perspectiva Plug and Play hay tres tipos de controladores de dispositivos:
Un controlador de BUS (bus driver): es un controlador de los servicios de BUS,
adaptador, puente (bridge) o cualquier dispositivo que tiene dispositivos ‘hijos’. Los
controladores de bus, son controladores necesarios y son suministrados
generalmente por Microsoft. Hay un controlador de bus por cada tipo de bus en el
sistema.
Un controlador de función function driver): es el controlador principal y suministra
la interface operacional para un dispositivo. Este controlador, es totalmente
necesario a no ser que el uso del dispositivo sea en ‘raw’ (en ‘crudo’). Esto puede
hacerse en ciertos dispositivos cuya implementación es dada en E/S por el
controlador de bus y cualquier numero de controladores de ‘filtro’. Los dirvers de
función para un disositivo stá tipicamente implementado como un para de
controlador / minicontrolador (driver/minidriver). En estos controladores pares, el
controlador de ‘clase’ (class driver) es usualmente escrito por Microsoft, y nos da la
funcionalidad requerida para todos los dispositivos de una ‘clase’ o tipo. Y el
minidriver, escrito usualmente por el fabricante de hardware, permite utilizar la
funcionalidad especifica del dispositivo.
Un controlador de ‘filtro’ (filter driver): ordena peticiones de E/S para u bus, un
dispositivo o una clase de dispositivos. Los controladores de filtro son opcionales y
pueden existir en cualquier número, colocado además, encima o debajo del driver
de función y por encima del driver de bus. Normalmente, los controladores de filtro
serán suministrados por los montadores (OEMs) o por los vendedores
independientes de hardware (IHVs).
En algunos casos, los controladores de filtro de bajo-nivel modifican las saldias de
un dispositivo hardware. Por ejemplo, un controlador de filtro de bajo-nivel para un
dispositivo de ratón puede suministrarnos el concepto de ‘aceleración’ permitiendo
una conversión ‘no lineal’ del movimiento del ratón.
Los controladores de filtro de alto-nivel, normalmente nos dan valores añadidos o
características para un dispositivo. Por ejemplo, un controlador de dispositivo de
filtro de alto-nivel para un teclado pudiera hacer cumplir chequeos adicionales de
seguridad.
Interfaces adicionales en Windows 2000.
Los controladores de Plug and Play en Windows 2000 no están limitados a usar
interfaces WDM. Los controladores pueden llamar a otras interfaces para soportar
dispositivos ‘legados’ (legacy devices) en Windows 2000, u otras capacidades
especificas que Windows 2000 que no son suministradas bajo WDM.
Debemos tener presente que un driver que soporte características especificas de
Windows 2000, no será compatible con Windows 98. Si un controlador va a ser
usado en ambos sistemas, solo deberán usarse interfaces WDM.
Controladores de bus WDM.
La Administración de Energía del bus y el Plug and Play están manejadas por
controladores de bus WDM, los cuales con controladores estandar WDM que tienen
esas capacidades especificas para el bus. Debemos hacer notar en este contexto
que cualquier dispositivo desde el cual se ‘enumeran’ otros dispositivos es lo que
denominamos ‘bus’. Un controlador de bus responde ahora a las nuevas peticiones
de Plug and Play y Administración de Energía mediante paquetes de petición de E/S
es decr: IRPs (I/O Request Packets) que además pueden extender sus
capacidades, usando controladores de filtro.
El controlador de bus, es el primer responsable de lo siguiente:





‘Enumerar’ los dispositivos en el bus
Informar dinámicamente de los sucesos en este bus al sistema
operativo.
Responder a las peticiones de los IRPs de Plug and Play y Administración
de Energía.
Multiplexar el acceso al bus (en algunos ‘buses’)
Generalmente, administrar los dispositivos que cuelgan de ese bus.
Durante la enumeración, un controlador de bus identifica los dispositivos en este
bus y creo dispositivos ‘objetos’ para ellos. El método usado por un controlador de
bus para identificar los dispositivos depende del bus en particular.
Microsoft suministra coontroladores de bus para los ‘buses’ más comunes, incluidos
los PCI, PnP ISA, SCSI y USB. Otros controladores de bus, pueden ser
suministrados por los IHVs o los OEMs. Un controlador de bus, puede ser
implementado como un par driver/minidriver de esta manera, por ejemplo, un
port/miniport SCSI controla una tarjeta adaptadora SCSI. En algunos ‘pares’ de
controladores de este estilo, uno de ellos en montado (linked) en el segundo
controlador y el segundo controlador es una DLL.
El controlador de ACPI realiza plenamente el papel de ambos: controlador de bus y
controlador de funcion.
El ACPI permite al sistema conocer los dispositivos que no tienen un metodo
estándar de enumeración en si mismos (como los dispositivos legados) o no han
sido correctamente construidos bajo las nuevas normas ACPI para ser enumerados
por el ACPI (como por ejemplo, un dispositivo LID o un dispositivo controlador
embebido). ACPI también instala controladores de filtro de alto-nivel para los
dispositivos que ‘rozan’ la funcionalidad estándar de ese bus. Por ejemplo, si en un
bus PCI montamos un controlador grafico cuyo control de Energía no está
soportada por el bus PCI, este dispositivo puede acceder a esa funcionalidad
añadida si el controlador de ACPI carga un controlador de filtro de alto-nivel para
él.
Controladores de dispositivos WDM
Los controladores de dispositivos WDM son usualmente el par ‘driver/minidriver’ y
los controladores de filtro que hemos visto previamente. Además para darnos la
interface operativa para un dispositivo los controladores de funcion juegan un papel
importante en el manejo de Energía en el sistema, añadiendo información como
puede ser el propietario de la ‘politica’ para el dispositvo y los posibles estados
desde la situación de ‘dormido’ a la situación de totalmente opertativo.
Componentes en modo user del Plug and Play.
Las APIs para controlar los dispositivos Plug and Play en Windows 2000 en modo
user son versiones extendidas de 32 bits del API del Administrador de
Configuración en Windows 95. El Administrador de Configuración es un controlador
de dispositivo virtual (VXD) el cual suministra sus rutinas como servicios tanto en
modo kernel como en modo user (componentes en ring 0 y ring 3 del procesador).
En Windows 2000, ests rutinas nos dan la funcionaldad desde el modo user del
Administrador de Plug and Play y son exclusivamente APIs en modo user. El
instalador de Windows 2000 instala estos controladores.
Windows 2000 nos suministra una APIs que las aplicaciones pueden usar para
ciertos tipos de hardware personalizado, administración de sucesos y crear nuevos
sucesos (eventos) de hardware.
Administración de Energía.

Permite al sistema operativo (OS) control directo sobre la
administración de energía

Define un método estándar para colocar al sistema entero o a parte de
él, a ‘dormir’

Puede también ser usado para el control de la temperatura.
Acerca del ACPI
La interface ACPI permite al sistema operativo un control directo sobre la
Administración de Energía y las funciones Plug and Play del ordenador. Cuando está
operativo, toma control sobre las funciones de las interfaces de las BIOS legadas
como las APM BIOS y PNPBIOS. Una vez realizado esto, el sistema operativo toma
la responsabilidad del manejo de los sucesos Plug and Play como el control de
Energia y estado de la temperatura basado en las opciones del usuario y en
peticiones de las aplicaciones. ACPI nos da el control a bajo-nivel que el sistema
puede tener con esas funciones. Las areas funcionales manejadas por las
especificaciones ACPI son:
Administración de Energía del Sistema.
ACPI define los mecanismos para poner al ordenador en situación de espera
(dormido). También nos da un mecanismo general para que cualquier dispositivo
pueda ‘despertar’ al ordenador.
Administración d Energía de los dispositivos.
Las tablas del ACPI, describen los dispositivos de la Placa Madre, sus estados de
Energía y los posibles estados de Energía de los dispositivos que están conectados
y controla la situación de los dispositivos en los diferentes estados de Energía. Esto
permite al sistema operativo para poner a cualquier dispositivo en situación de
ahorro de energía basándose en el uso de él por parte de las aplicaciones.
Administración de Energía del procesador.
Cuando el sistema operativo no está ocupado (pero tampoco está ‘durmiendo’),
puede usar los comandos descritos por la especificación ACPI para poner a los
procesadores en estados de bajo-consumo.
Plug and Play.
El ACPI especifica la información usada para enumerar y configurar los dispositivos
conectados a la placa madre. Esta información es del tipo jerárquico. Cuando existe
sucesos como ‘pinchar’ o ‘quitar’ un dispositivo de su sitio, el sistema operativo
precisa conocer que otros dispositivos van a ser afectados por el suceso. Poe
ejmplo, al eliminar un HUB USB, todos los dispositivos que cuelgan jerárquicamente
de él, serán eliminados.
Sucesos del Sistema.
El ACPI nos da un mecanismo general de sucesos que puede ser usado por los
sucesos del sistema como son: sucesos térmicos, sucesos de administración de
energía, pinchar un dispositivo o quitarlo, etc. Este mecanismo es verdaderamente
flexible y en sí mismo, no especifica explícitamente cuantos sucesos son
encaminados al núcleo lógico del chipset.
Administración de la batería.
La política de la Administración de la batería desplaza el control de las bios APM al
ACPI. El sistema operativo determina el estado de batería baja y avisos de la
batería y calcula la capacidad remanente en ella. Un dispositivo de batería ACPI
compatible necesita la interface del subsistema Smart Battery que es controlado
directamente por el sistema operativo a través de una interface de controlador
embebido o un Control Method Battery (CMBatt) Interface. Una interface CMBAtt
está totalmente definida por los métodos de control AML, permitiendo a los OEM
escoger cualquier tipo de batería y cualquier tipo de interface de comunicación
soportada por el ACPI.
Administración de Temperatura.
El sistema operativo controla los estados de Energía de los dispositivos y los
procesadores. ACPI también dirige la administración de los sucesos de temperatura.
Suministra un modelo simple y escalable para permitir a los OEMs definir zonas
calientes. Indicadores termicos y métodos para la ventilación de las zonas calientes.
Controlador Embebido.
ACPI define una interface estándar de comunicaciones hardware y software entre
un enumerador de bus del sistema operativo y un controlador embebido. Esto
permite a cualquier sistema operativo a dar un enumerador de bus estándar que
puede comunicarse directamente con un controlador embebido en el sistema
permitiendo a los otros controladores comunicarse y usar los recursos de los
controladores embebidos del sistema.
Control del Administrador del Bus del Sistema.
ACPI define una interface estándar de comunicaciones hardware y software entre
un controlador de bus del sistema y un controlador SMBus. Esto permite a cualquier
sistema operativo el poder comunicarse directamente con dispositivos SMBus en el
sistema.