Diapositiva 1

1
Windows Driver Foundation (WDF)
Presentación hecha por Janeth Mapel Mapel
Luis Jesús Soto Sánchez Emmanuel Montero
Sánchez
2
Qué es WDF?
3

• 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.

4

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

5

• 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.

6
Herramientas de WDF para el desarrollo de drivers
7

• 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
• Propiedades.- describen las características del
  objeto, a las cuales se acceden a través de
  métodos.
• Métodos.- realizan acciones sobre los objetos.
• Eventos.- son condiciones sobre las cuales el
  driver debe tomar una acción

8
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)
9

• 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.

10
(No Transcript)
11
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

12
En la figura se muestra el flujo de I/O para el
driver WDF modo-usuario
13
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.

14

• 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

15
Estado maquinaPlug 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.

16
I/O FLOW AND DISPATCHING IN WDF DRIVERS
17
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

18
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.

19
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.

20
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

21
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

22
SUMARIO DE PETICIONES DE I/O
23
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

24

• 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.

25
BUFFERED I/O

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

26
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

27
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.

28
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ó.

29
I/O REQUEST PATH FROM APPLICATION TO DEVICE
30
I/O REQUEST PATH THROUGH THE UMDF DEVICE STACK
31
I/O REQUEST PATH THROUGH A KMDF DRIVER