Rutinas dispatchPnP

La rutina DispatchPnP de un controlador admite Plug and Play controlando irP para el código de función de E/S de IRP_MJ_PNP. Asociados con el código de función IRP_MJ_PNP son varios códigos de función de E/S menores (consulte Plug and Play IRP secundarias), algunos de los cuales todos los controladores deben controlarse y algunos de los cuales se pueden controlar opcionalmente. El administrador de PnP usa estos códigos de función menores para dirigir los controladores para iniciar, detener y quitar dispositivos y consultar controladores sobre sus dispositivos.

Todos los controladores de un dispositivo deben tener la oportunidad de controlar los IRP de PnP para el dispositivo, excepto en algunos casos en los que se permite que una función o un controlador de filtro produzcan un error en el IRP.

La rutina DispatchPnP de cada controlador debe seguir estas reglas:

• Un controlador de filtro o función debe pasar IRP de PnP al siguiente controlador de la pila de dispositivos, a menos que la función o el controlador de filtro controle el IRP y encuentre un error (debido a recursos insuficientes, por ejemplo).

  Todos los controladores de un dispositivo deben tener la oportunidad de controlar los IRP de PnP para el dispositivo a menos que uno de los controladores encuentre un error. El administrador de PnP envía IRP al controlador superior de una pila de dispositivos. Los controladores de función y filtro pasan el IRP al siguiente controlador y el controlador primario del bus completa el IRP. Consulte Pasar IRP de PnP hacia abajo en la pila de dispositivos para obtener más información.

  Un controlador puede producir un error irP si intenta controlar el IRP y encuentra un error (por ejemplo, recursos insuficientes). Si un controlador recibe un IRP con un código que no controla, el controlador no debe producir un error en el IRP. Debe pasar este TIPO de IRP al siguiente controlador sin modificar el estado del IRP.

• Un controlador debe controlar determinados IRP de PnP y, opcionalmente, puede controlar otros.

  Cada controlador PnP es necesario para controlar determinados IRP, como IRP_MN_REMOVE_DEVICE, y puede controlar opcionalmente otros. Consulte Plug and Play IRP menores para obtener información sobre qué IRP son necesarios y opcionales para cada tipo de controlador (controladores de función, controladores de filtro y controladores de autobús).

  Un controlador puede producir un error en un IRP de PnP necesario con un estado de error adecuado, pero un controlador no debe devolver STATUS_NOT_SUPPORTED para un IRP de este tipo.

• Si un controlador controla correctamente un IRP de PnP, el controlador establece el estado irP como correcto. No depende de otro controlador de la pila para establecer el estado.

  Un controlador establece Irp-IoStatus.Status> en STATUS_SUCCESS para informar al administrador de PnP de que el controlador controló el IRP correctamente. Para algunos IRP, es posible que un controlador que no sea de bus pueda confiar en su controlador de bus primario para establecer el estado como correcto. Sin embargo, esta es una práctica arriesgada. Para lograr coherencia y solidez, un controlador debe establecer el estado irP en correcto para cada IRP de PnP que controla correctamente.

• Si un controlador produce un error en un IRP, el controlador completa el IRP con un estado de error y no pasa irP al siguiente controlador.

  Para producir un error en un IRP como IRP_MN_QUERY_STOP_DEVICE, un controlador establece Irp-IoStatus.Status> en STATUS_UNSUCCESSFUL. Los valores de estado de error adicionales para otros IRP incluyen STATUS_INSUFFICIENT_RESOURCES y STATUS_INVALID_DEVICE_STATE.

  Los controladores no establecen STATUS_NOT_SUPPORTED para los IRP que controlan. Este es el estado inicial establecido por el administrador de PnP. Si un IRP se completa con este estado, significa que ningún controlador de la pila controló el IRP; todos los controladores acaban de pasar el IRP al siguiente controlador.

• Un controlador debe controlar un IRP de PnP en su rutina de envío (en el camino hacia abajo de la pila del dispositivo), en una rutina de IoCompletion (en la forma en que el IRP realiza una copia de seguridad de la pila de dispositivos), o ambos, tal como se especifica en la página de referencia del IRP.

  Algunos IRP de PnP, como IRP_MN_REMOVE_DEVICE, deben controlarse primero por el controlador en la parte superior de la pila de dispositivos y, a continuación, por cada controlador inferior siguiente. Otros, como IRP_MN_START_DEVICE, deben controlarse primero por el controlador de autobús primario. Otros, como IRP_MN_QUERY_CAPABILITIES, se pueden controlar tanto en la parte posterior de la pila del dispositivo como en la copia de seguridad. Consulte Plug and Play IRP secundarias para conocer las reglas que se aplican a cada IRP de PnP. Consulte Posponer el procesamiento de IRP de PnP hasta que finalicen los controladores inferiores Para obtener información sobre cómo controlar los IRP de PnP que el controlador de bus primario debe procesar primero.

• Un controlador debe agregar información a un IRP en el camino hacia abajo de la pila de dispositivos y modificar o quitar información sobre la copia de seguridad del IRP.

  Al devolver información en respuesta a un IRP de consulta PnP, un controlador debe seguir esta convención para habilitar la información ordenada que pasan los controladores superados para un dispositivo.

• Excepto cuando se documenta explícitamente, un controlador no debe depender de que los IRP de PnP se envíen en un orden determinado.

• Cuando un controlador envía un IRP de PnP, debe enviar el IRP al controlador superior de la pila de dispositivos.

  La mayoría de los IRP de PnP los envía el administrador de PnP, pero algunos pueden enviarse mediante controladores (por ejemplo, IRP_MN_QUERY_INTERFACE). Un controlador debe enviar un IRP de PnP al controlador en la parte superior de la pila de dispositivos. Llame a IoGetAttachedDeviceReference para obtener un puntero al objeto de dispositivo para el controlador en la parte superior de la pila de dispositivos.