Compartir a través de

Procedimientos recomendados: Uso de direcciones URL

  • Artículo

En este tema se describen los procedimientos recomendados para un controlador cliente para asignar, compilar y enviar un URB a la pila de controladores USB incluida con Windows 8.

Windows 8 incluye una nueva pila de controladores USB para admitir dispositivos Universal Serial Bus (USB) 3.0. La nueva pila de controladores USB 3.0 implementa varias funcionalidades nuevas, según la especificación USB 3.0. Además, la pila de controladores incluye otras funcionalidades que permiten a un controlador cliente realizar tareas comunes de forma eficaz. Por ejemplo, la nueva pila de controladores acepta MDL encadenados que permite al controlador cliente enviar un búfer de transferencia en páginas desconcertantes en memoria física.

Para que un controlador cliente pueda usar las nuevas funcionalidades de la pila de controladores USB para Windows 8, el controlador debe registrarse en la pila de controladores USB subyacente que Windows carga para el dispositivo. Para registrar el controlador cliente, llame a USBD_CreateHandle y especifique una versión del contrato. Si el controlador de cliente está pensado para compilar, ejecutar y usar las mejoras y las nuevas funcionalidades de Windows 8, la versión del contrato de cliente se USBD_CLIENT_CONTRACT_VERSION_602.

En el caso de un controlador de cliente de versión de USBD_CLIENT_CONTRACT_VERSION_602, la pila de controladores USB asume que el controlador cliente se ajusta al siguiente conjunto de reglas:

La pila del controlador USB realiza validaciones en las solicitudes recibidas y controla las infracciones siempre que sea posible. Si no lo hace, podría provocar un comportamiento indefinido.

No enviar solicitudes de E/S mediante identificadores de canalización obsoletos o no válidos

El controlador cliente no debe usar identificadores de canalización obsoletos para enviar solicitudes de E/S a la pila del controlador USB. Un identificador de canalización obsoleta hace referencia a un identificador de canalización que se obtuvo en una solicitud para seleccionar una configuración, una interfaz o una configuración alternativa que ya no está seleccionada en el dispositivo. Para evitar identificadores de canalización obsoletos, cada vez que el controlador cliente selecciona una configuración o una interfaz, el controlador debe actualizar su caché de identificadores de canalización (normalmente almacenados en el contexto del dispositivo). Ciertas condiciones de carrera también pueden dar lugar a manijas de tubería obsoletas. Por ejemplo, el controlador de cliente envía una solicitud de E/S mediante un identificador de canalización en la interfaz seleccionada. Antes de que se complete la solicitud, el controlador cliente selecciona una configuración alternativa que no usa el mismo punto de conexión asociado al identificador de canalización en uso. Ambas solicitudes pendientes pueden provocar una condición de carrera que hace que el identificador de canalización no sea válido.

Asignar direcciones URL mediante una llamada a rutinas de asignación en Windows 8

Windows 8 proporciona nuevas rutinas para asignar, compilar y liberar bloques de solicitudes USB (URB). Para asignar direcciones URL, un controlador cliente de Windows Driver Model (WDM) siempre debe usar las nuevas rutinas que se muestran en la lista siguiente:

Las rutinas de la lista anterior pueden adjuntar un contexto URB opaco al URB asignado para mejorar el seguimiento y el procesamiento. El controlador cliente no puede ver ni modificar el contenido del contexto URB. Para obtener más información sobre la asignación de URB en Windows 8, vea Asignar y compilar direcciones URL.

Si un controlador cliente de Windows Driver Framework (WDF) que identifica su versión como USBD_CLIENT_CONTRACT_VERSION_602 durante el registro (consulte WdfUsbTargetDeviceCreateWithParameters), la pila de controladores USB espera que el controlador cliente asigne memoria para el URB llamando al nuevo WdfUsbTargetDeviceCreateUrb.

No reutilizar las direcciones URL activas asociadas a solicitudes pendientes

La pila de controladores USB comprueba deliberadamente si detecta que se ha vuelto a enviar un URB activo antes de la solicitud asociada con el URB. Un URB está activo siempre que la solicitud esté pendiente y no se haya llamado a la rutina de finalización de IRP del controlador de cliente. No realice las siguientes tareas en un URB activo.

  • No vuelva a enviar un URB activo para otra solicitud (asocie el URB con otro IRP).
  • No modifique el contenido de un URB activo.
  • No libere un URB activo.

Después de llamar a la rutina de finalización del controlador cliente, los controladores pueden volver a enviar direcciones URL para determinados tipos de solicitud dentro de la rutina de finalización. Las reglas siguientes se aplican a las reenvíos:

  • El controlador cliente no debe reutilizar un URB asignado por USBD_SelectConfigUrbAllocateAndBuild para cualquier tipo de solicitud que no sea una solicitud de configuración de selección para seleccionar la misma configuración.

  • El controlador cliente no debe reutilizar un URB asignado por USBD_SelectInterfaceUrbAllocateAndBuild para cualquier tipo de solicitud que no sea una solicitud de interfaz de selección para seleccionar la misma configuración alternativa en una interfaz. Para obtener un ejemplo, vea Comentarios en USBD_SelectInterfaceUrbAllocateAndBuild.

  • Un URB asignado por USBD_IsochUrbAllocate solo se debe reutilizar para las solicitudes de transferencia isócrónicas. Por el contrario, no se debe usar un URB asignado para otros tipos de solicitudes de E/S (control, masiva o interrupción) para una solicitud isócrónica.

    Por ejemplo, un controlador de cliente asigna y crea una estructura URB para una solicitud de transferencia masiva. El controlador de cliente también quiere enviar datos a puntos de conexión isócronos en el dispositivo. Una vez completada una solicitud de transferencia masiva, el controlador de cliente no debe volver a formatear y enviar el URB para una solicitud isócrónica. Esto se debe a que un URB asociado a una solicitud isócrónica tiene una longitud variable en función del número de paquetes. Además, los paquetes son necesarios para iniciar y finalizar en un límite de marco. Es posible que el URB asignado (para la transferencia masiva) no se ajuste al diseño del búfer necesario para una transferencia isócrónica y se produzca un error en la solicitud.

  • Un URB asignado por USBD_UrbAllocate no se debe reutilizar para un isócrono, una configuración de selección o una solicitud select-interface. El URB se puede reutilizar para seleccionar una configuración NULL para deshabilitar la configuración seleccionada en el dispositivo. El URB no debe estar activo y el controlador de cliente debe volver a formatear el URB llamando a la macro UsbBuildSelectConfigurationRequest y pasando NULL en el parámetro ConfigurationDescriptor .

  • Antes de volver a enviar un URB, el controlador cliente debe volver a formatear el URB mediante la macro UsbBuildXxx adecuada definida para el tipo de solicitud. Es importante que el controlador dé formato a la URB, ya que la pila USB podría haber modificado parte de su contenido.

    Por ejemplo, supongamos que un controlador llama a UsbBuildInterruptOrBulkTransferRequest para inicializar un URB para una solicitud de transferencia masiva (consulte _URB_BULK_OR_INTERRUPT_TRANSFER). Si el controlador inicializa el miembro TransferBufferMDL de la estructura URB en NULL, la pila del controlador USB usa el búfer de transferencia, especificado TransferBuffer, en para intercambiar datos con el dispositivo en lugar de una MDL. Sin embargo, internamente, la pila de controladores USB podría crear una MDL, almacenar un puntero al MDL en TransferBufferMDL y usar mdL para pasar los datos de la pila. Aunque la pila del controlador USB libera la memoria MDL, TransferBufferMDL podría no ser NULL cuando el controlador cliente está procesando el URB en la rutina de finalización. Para asegurarse de que los miembros del URB tienen el formato correcto, el controlador debe llamar a UsbBuildInterruptOrBulkTransferRequest de nuevo para volver a formatear el URB antes de enviar la solicitud,

No use el período de sondeo mayor que 8 para transferencias isócrónicas de alta velocidad y SuperSpeed

La pila del controlador USB admite tuberías isócrónicas de alta velocidad y SuperSpeed con un número de período de sondeo de 1, 2, 4 o 8. Un controlador de cliente no debe enviar E/S a un punto de conexión que tenga un período superior a 8. Si lo hace, podría provocar una comprobación de errores.

Asegúrese de que el número de paquetes isócronos que es un múltiplo de paquetes por fotograma

Para transferencias isócrónicas de alta velocidad y SuperSpeed, el número de paquetes isócronos por fotograma se calcula como 8 /período de sondeo. El controlador cliente debe asegurarse de que el valor NumberOfPackets especificado en el URB (vea _URB_ISOCH_TRANSFER) es un múltiplo de paquetes por fotograma.

La pila del controlador USB no admite direcciones URL de transferencia isócrónica en las que numberOfPackets no es un múltiplo de paquetes por fotograma.

Llamar a la rutina en el nivel de IRQL documentado

Si registra el controlador cliente con USBD_CLIENT_CONTRACT_VERSION_602 como versión del contrato, la pila de controladores USB supone que el controlador cliente envió la solicitud en el nivel de IRQL adecuado. Si un controlador cliente envía una solicitud a DISPATCH_LEVEL, que se debe enviar en PASSIVE_LEVEL. Al recibir la solicitud, en algunos casos, la pila del controlador USB valida el valor IRQL y produce un error en la solicitud. Sin embargo, en otros casos, la pila del controlador USB podría generar una comprobación de errores.

Envío de solicitudes a un dispositivo USB