Windows Driver Foundation (WDF) Presentación hecha por: Janeth Mapel Mapel Luis Jesús Soto Sánchez Emmanuel Montero Sánchez

¿Qué es WDF?

Según Wikipedia: es un conjunto de herramientas de Microsoft que auxilia en la creación de drivers confiables y de alta calidad para Windows 2000 y versiones posteriores. Según Microsoft: nuestra siguiente generación de modelos desarrolladores de drivers. Según Yo: una estrategia de Microsoft para globalizar otra área de la informática, en este caso el desarrollo de drivers muy a su estilo.

¿Por qué WDF? Exceso de drivers en el mercado Problemas de compatibilidades Beneficios para las empresas y los usuarios

Características básicas de WDF  Practicidad al desarrollar drivers.- ofrece un modelo de programación orientado a objetos, que ayuda al desarrollador a programar mas fácilmente los drivers, evitándole tener que realizar las operaciones básicas y de interacción con el SO, para enfocarse en las funciones especificas del driver a las que luego se podrán añadir otras.  Soporta tanto modo Kernel como modo User.  Contiene herramientas para verificar drivers y es compatible con otras existentes.  Simplifica el manejo de Plug and Play y administración de energía.

Herramientas de WDF para el desarrollo de drivers

Objetos en WDF Para simplificar la programación del comportamiento de un driver WDF maneja el concepto de “objetos”, que representan términos comunes para el driver como dispositivos, colas y solicitudes. Estos objetos se componen de 3 elementos I.Propiedades.- describen las características del objeto, a las cuales se acceden a través de métodos. II.Métodos.- realizan acciones sobre los objetos. III.Eventos.- son condiciones sobre las cuales el driver debe tomar una acción

Frameworks Son los encargados de proveer al desarrollador los elementos básicos y la estructura de un driver, apoyándose en el manejo de objetos de WDF. Se puede decir que proporcionan la “plantilla” a partir de la cual se comienza el desarrollo. Existen dos tipos en WDF: Kernel-Mode Driver Framework (KMDF) User-Mode Driver Framework (UMDF)

Kernel-Mode Driver Framework (KMDF) Sirve para escribir drivers para dispositivos en modo Kernel. Proporciona el esqueleto básico para la creación de un driver Kernel. Esta basado en el lenguaje C API No es parte del SO Kernel sino que trabaja de modo paralelo a este, como una librería aparte. Tipos de drivers Kernel que soporta: Drivers de función y filtro para dispositivos Plug and Play Drivers para Bus Drivers de control para dispositivos variados Maneja sus propios tipos de objetos.

Nombre del objetoFuncion WDFDRIVERRepresenta el objeto driver WDFDEVICERepresenta el objeto dispositivo WDFQUEUERepresenta una cola para una peticion I/O WDFINTERRUPTRepresenta una fuente de interrupcion WDFREQUESTDescribe una peticion I/O WDFMEMORYDescribe un buffer para una peticion I/O WDFDMAENABLERDescribe las caracteristicas de todas las transferencias DMA (direct memory access) para el dispositivo WDFDMATRANSACTIONManeja operaciones para peticiones DMA individuales WDFIOTARGETRepresenta el driver que es el objetivo de una peticion I/O

UMDF (User-Model Driver Framework) El UMDF implementa un subconjunto de funcionalidades del KMDF como:  Soporte para Plug and Play.  Administración de energía.  O/I asíncronos. El UDMF provee un ambiente de operación simple Los drivers modo usuario solo tienen acceso a su propio espacio de dirección, usan el Win32 Api. Contribuyen a la estabilidad del sistema y seguridad. No pueden manipular directamente el hardware, manejar interrupciones, ni ejecutar DMA (Acceso directo a la memoria). Con el uso del UDMF se pueden crear drivers para algunos protocolos o dispositivos de bus serial

En la figura se muestra el flujo de I/O para el driver WDF modo-usuario

Soporte Plug and Play y Administrador de energía El manejo de Plug and Play y eventos de energía es importante para la confiabilidad del sistema, pero es complejo para su correcta implantación. El correcto manejo depende de la posición de los drivers en la pila del dispositivo, el estado de corriente del dispositivo, el estado de corriente del sistema de operación y el estado de cambio inminente del dispositivo o sistema. Los drivers requieren código para manejar las peticiones que aun no soportan. WDF se concentra en condición de rastreo y toma de decisiones en los framework.

WDF soporta Plug and Play y administrador de energía, es basado en los siguientes principios: El driver debería no ser requerido para interpretar o responder cada peticion tediosa en lugar de eso, debería manejar solo las respuestas que son relevantes para el dispositivo. Los framework deberían facilitar el comportamiento de errores para un abundante grupo de plug and play y fases de energía, incluso, bloqueo, eliminación, expulsión de dispositivos Acción WDF para cada punto debería ser bien definido y predecible. Plug and play y el administrador de energía deberían ser cuidadosamente integrado con otras partes del framework. Los framework deberían soportar tanto como hardware simple y complejo y diseño de driver. Un driver debería ser capaz de dominar cualquier falla de abastecimiento de framework

Estado maquina Plug and Play/ Administrador de energia WDF implementa Plug and play y administrador de energía en estado maquina. Un driver incluye llamadas de vuelta, así que puede ejecutar acciones de dispositivos en especifico en estado individual en la maquina. En cada transición estado un determinado conjunto de eventos es valido por cada tipo de objetos, los framework invocan sus retrollamadas para estos eventos en orden definido.

I/O FLOW AND DISPATCHING IN WDF DRIVERS

DISEÑO El tema fundamental para el diseño de controladores I/O es el tipo de peticiones de estos controladores Las peticiones mas comunes de estos drivers son: –Crear –Cerrar –Leer –Y el control de dispositivos I/O

PETICIÓN “CREAR” Comúnmente una aplicación abre un archivo, directorio o dispositivo llamando a la función de Windows CreateFile. Si la petición es correcta el sistema regresa un manejador de archivo el cual la aplicación puede representar I/O. el manejador especifica al proceso, no al metodo, que lo ah creado. La aplicación provee el manejador en todas las peticiones de I/O para identificar el objetivo de la peticion.

PETICIONES “LIMPIAR Y CERRAR” Una aplicación comúnmente llama a la función de Windows CloseHandle cuando ya no requiere mas del Handle. En respuesta, el administrador de I/O decrementa el contador del handle para el archivo asociado. Después todos los handles del archivo tienen que ser cerrados, el administrador de I/O envía una petición Cleanup al driver, en respuesta a la petición el driver cancela todas las peticiones de I/O para el archivo asociado.

PETICIONES “LECTURA Y ESCRITURA” Una de las tareas mas comunes de una aplicación es la petición de lectura y escritura, esto lo hace llamando a las funciones de Windows ReadFile y WriteFile. La tarea de las peticiones es recuperar datos de, o proveer datos a, a un dispositivo en particular por medio de un handle. Cada petición de lectura incluye un buffer en el cual el driver regresa el dato solicitado y en la petición de escritura incluye también un buffer que contiene el dato que será escrito. La aplicación describe

PETICIÓN “CONTROL DE DISPOSITIVOS I/O” La peticion de control de dispositivos I/O se hace llamando la funcion de Windows DeviceIocontrol, peticiones semejantes son tambien llamadas “controladores de dispositivos” “controladores de I/O” o simplemente “IOCTLs”, los componentes en el modo Kernel pueden definir y usar peticiones de control de dispositivos I/O,algunas veces llamadas IOCTLs. En el modo usuario las aplicaciones y los drivers no pueden usar estas peticiones

SUMARIO DE PETICIONES DE I/O WDM IRP major function codeComments IRP_MJ_CLEANUPSupported through immediate callbacks on a file object; not queued. IRP_MJ_CLOSESupported through immediate callbacks on a file object; not queued. IRP_MJ_CREATESupported through queues for both KMDF and UMDF, and through immediate callbacks on a device object for KMDF only. IRP_MJ_DEVICE_CONTROLSupported through queues. IRP_MJ_INTERNAL_DEVICE_CONTR OL Supported through queues for KMDF only. IRP_MJ_PNPSupported through state-specific callbacks on a device object. IRP_MJ_POWERSupported through state-specific callbacks on a device object. IRP_MJ_READSupported through queues. IRP_MJ_SHUTDOWNSupported for control (non-Plug and Play) device objects in KMDF only. IRP_MJ_SYSTEM_CONTROLSupported through WMI objects in KMDF only. IRP_MJ_WRITESupported through queues.

TIPOS DE TRANSFERENCIA I/O Windows soporta los siguientes tres mecanismos de transferencia de datos, tambien llamados “tipos de transferencia I/O”: –Buffered I/O –Direct I/O –Neither buffered nor directed I/O

Los driver de WDF pueden soportar cualquiera de los 3 tipos de transferencia antes mencionados. Para las peticiones de control de dispositivos I/O, el código incluye el tipo de transferencia, entonces un IOCTLS del dispositivo puede usar uno de los 3 tipos de transferencia. Toda petición de lectura y escritura a un driver debe usar el mismo tipo de transferencia porque el tipo de transferencia para peticiones de lectura y escritura están asociados.

BUFFERED I/O Cuando el administrador I/O envia una peticion para buffered I/O,el IRP contiene una copia interna del caller’s buffer. El administrador copia datos del caller’s buffer a el buffer interno durante una peticion de escriturao de el buffer interno al caller’s buffer cuando el driver completa la peticion de lectura.

DIRECT I/O Cuando el administrador envía una petición Direct I/O, el IRP contiene la dirección de una MDL que describe la petición del buffer. Para un driver UMDF, el reflector calcula la longitud del buffer y el modo de acceso y copia esta información dentro del buffer en el proceso del host. El driver recibe el nuevo buffer en la petición WDF. El driver UMDF lee y escribe este buffer tal y como cualquier otro buffer

COMPORTAMIENTO DEL REFLECTOR. Si el código de control especifica METHOD_OUT_DIRECT, el reflector copia el contenido del buffer de entrada al proceso del host Si el código de control especifica METHOD_IN_DIRECT, el reflector copia inicialmente los buffers de entrada y salida al proceso del host, porque el buffer de salida puede también funcionar como un buffer de entrada adicional, cuando la petición esta completa, el reflector coipa el contenido en un buffer de salida de el proceso del host regresa al IRP original.

NEITHER BUFFEREF NOR DIRECT I/O Cuando el administrador I/O envía una petición de control de dispositivos I/O que especifica el tipo de transferencia METHOD_NEITHER, el IRP contiene un apuntador al buffer user-mode que fue suplido por la aplicación que la petición realizó.

I/O REQUEST PATH FROM APPLICATION TO DEVICE

I/O REQUEST PATH THROUGH THE UMDF DEVICE STACK

I/O REQUEST PATH THROUGH A KMDF DRIVER