Procedury związane z DispatchPnP

Procedura DispatchPnP sterownika wspiera Plug and Play, obsługując IRP dla kodu funkcji I/O IRP_MJ_PNP. Z kodem funkcji IRP_MJ_PNP jest związanych kilka pomocniczych kodów funkcji we/wy (zobacz Plug and Play Minor IRPs), z których niektóre muszą być obsługiwane przez wszystkie sterowniki, a niektóre mogą być obsługiwane opcjonalnie. Menedżer PnP używa tych kodów funkcji pomocniczych do kierowania sterownikami w celu uruchamiania, zatrzymywania i usuwania urządzeń oraz do wykonywania zapytań do sterowników dotyczących ich urządzeń.

Wszystkie sterowniki dla urządzenia muszą mieć możliwość obsługi protokołu PnP IRPs dla urządzenia, z wyjątkiem kilku przypadków, w których funkcja lub sterownik filtru może zakończyć się niepowodzeniem protokołu IRP.

Procedura DispatchPnP każdego sterownika musi być zgodna z następującymi regułami:

• Sterownik funkcji lub filtru musi przekazać IR-y PnP do następnego sterownika w stosie urządzenia, chyba że sterownik funkcji lub filtru obsługuje IRP i napotka błąd (na przykład z powodu niewystarczających zasobów).

  Wszystkie sterowniki dla urządzenia muszą mieć możliwość obsługi protokołu PnP IRPs dla urządzenia, chyba że jeden z sterowników napotka błąd. Menedżer pnP wysyła irps do najwyższego sterownika w stosie urządzenia. Sterowniki funkcji i filtru przekazują protokół IRP do następnego sterownika, a sterownik magistrali nadrzędnej kończy protokół IRP. Aby uzyskać więcej informacji, zobacz Przekazywanie PnP IRPs w dół stosu urządzeń.

  Sterownik może odrzucić IRP, jeśli spróbuje go obsłużyć i napotka błąd (na przykład niewystarczające zasoby). Jeśli sterownik odbiera protokół IRP z kodem, który nie obsługuje, sterownik nie może zakończyć się niepowodzeniem protokołu IRP. Musi przekazać taki protokół IRP do następnego sterownika bez modyfikowania stanu protokołu IRP.

• Sterownik musi obsługiwać niektóre środowiska IRP PnP i może opcjonalnie obsługiwać inne.

  Każdy sterownik PnP musi obsługiwać pewne IRPs, takie jak IRP_MN_REMOVE_DEVICE, i może opcjonalnie obsługiwać inne. Aby uzyskać informacje na temat wymaganych i opcjonalnych IRP dla każdego rodzaju sterowników (sterowników funkcji, sterowników filtrów i sterowników magistrali), zobacz Plug and Play Minor IRPs.

  Sterownik może zakończyć niepowodzeniem wymagane PnP IRP z odpowiednim stanem błędu, ale nie może zwrócić STATUS_NOT_SUPPORTED dla takiego IRP.

• Jeśli sterownik pomyślnie obsługuje protokół IRP pnP, sterownik ustawia stan IRP na powodzenie. Nie zależy od innego sterownika w stosie, aby ustawić stan.

  Sterownik ustawia parametr Irp-IoStatus.Status> na STATUS_SUCCESS, aby poinformować menedżera PnP, że sterownik pomyślnie obsłużył protokół IRP. W przypadku niektórych IRPs, sterownik inny niż autobusowy może być w stanie polegać na swoim nadrzędnym sterowniku magistrali, aby ustawić status na pomyślny. Jest to jednak ryzykowna praktyka. Aby zapewnić spójność i niezawodność, sterownik musi ustawić stan IRP na powodzenie dla każdego protokołu IRP pnP, który obsługuje pomyślnie.

• Jeśli sterownik ulegnie awarii IRP, sterownik ukończy protokół IRP ze stanem błędu i nie przekazuje IRP do następnego sterownika.

  Aby spowodować niepowodzenie IRP, takiego jak IRP_MN_QUERY_STOP_DEVICE, sterownik ustawia Irp->IoStatus.Status na STATUS_UNSUCCESSFUL. Dodatkowe wartości stanu błędu dla innych IRP obejmują STATUS_INSUFFICIENT_RESOURCES i STATUS_INVALID_DEVICE_STATE.

  Sterowniki nie ustawiają STATUS_NOT_SUPPORTED dla obsługiwanych przez nie żądań IRP. Jest to początkowy stan ustawiony przez menedżera PnP. Jeśli protokół IRP został ukończony z tym stanem, oznacza to, że żadne sterowniki w stosie nie obsługiwały protokołu IRP; wszystkie sterowniki właśnie przekazały protokół IRP do następnego sterownika.

• Sterownik musi obsługiwać PnP IRP w swojej procedurze wysyłającej (w drodze IRP w dół stosu urządzenia), w procedurze IoCompletion (w drodze IRP w górę stosu urządzenia) lub w obu przypadkach, jak określono na stronie referencyjnej dla IRP.

  Niektóre elementy IRP PnP, takie jak IRP_MN_REMOVE_DEVICE, muszą być najpierw obsługiwane przez sterownik w górnej części stosu urządzenia, a następnie przez każdy następny niższy sterownik. Inne, takie jak IRP_MN_START_DEVICE, muszą być najpierw obsługiwane przez sterownik magistrali nadrzędnej. Nadal inne, takie jak IRP_MN_QUERY_CAPABILITIES, można obsługiwać zarówno w dół, jak i w górę stosu urządzenia. Zobacz Plug and Play Minor IRPs, aby uzyskać reguły, które mają zastosowanie do każdego IRP PnP. Zobacz Postponing PnP IRP Processing Until Lower Drivers Finish (Opóźnienie przetwarzania IRP PnP do czasu zakończenia operacji przez niższe sterowniki), aby uzyskać informacje o obsłudze IRP PnP, które muszą najpierw być przetwarzane przez sterownik magistrali nadrzędnej.

• Sterownik musi dodać informacje do IRP, gdy IRP przemieszcza się w dół stosu urządzenia, oraz zmodyfikować lub usunąć informacje, gdy IRP wraca w górę stosu.

  Podczas zwracania informacji w odpowiedzi na IRP zapytania PnP sterownik musi postępować zgodnie z tą konwencją, aby umożliwić uporządkowane przekazywanie informacji przez sterowniki warstwowe dotyczące urządzenia.

• Z wyjątkiem przypadków jawnego udokumentowania, sterownik nie może zależeć od IRP PnP wysyłanych w żadnej określonej kolejności.

• Gdy sterownik wysyła żądanie IRP PnP, musi wysłać to żądanie do górnego sterownika w stosie urządzenia.

  Większość adresów IR PnP jest wysyłanych przez menedżera PnP, ale niektóre mogą być wysyłane przez sterowniki (na przykład IRP_MN_QUERY_INTERFACE). Sterownik musi wysłać protokół IRP pnP do sterownika w górnej części stosu urządzenia. Wywołaj IoGetAttachedDeviceReference, aby uzyskać wskaźnik do obiektu urządzenia dla sterownika na szczycie stosu urządzenia.