Tworzenie żądań IOCTL w sterownikach

Sterownik klasy lub inny sterownik wyższego poziomu może przydzielić pakiety IRP dla żądań kontroli we/wy i wysłać je do następnego niższego sterownika w następujący sposób:

1. Przydzielanie lub ponowne używanie pakietu żądania we/wy (IRP) przy użyciu głównego kodu funkcji IRP_MJ_DEVICE_CONTROL lub IRP_MJ_INTERNAL_DEVICE_CONTROL. Możesz użyć procedury IoBuildDeviceIoControlRequest, aby przydzielić IOCTL IRP. Można również użyć ogólnych rutyn tworzenia i inicjowania IRP, takich jak IoAllocateIrp, IoReuseIrp lub IoInitializeIrp. Aby uzyskać więcej informacji na temat alokacji IRP, zajrzyj do Creating IRPs for Lower-Level Drivers (Tworzenie IRP dla sterowników Lower-Level).

2. Skonfiguruj lokalizację stosu we/wy niższego sterownika dla IRP z kodem IOCTL_XXX i odpowiednimi parametrami.

3. Jeśli żądanie IOCTL ma zostać ukończone asynchronicznie, wywołaj procedurę KeInitializeEvent , aby zainicjować obiekt zdarzenia jako zdarzenie powiadomienia. Sterownik używa tego zdarzenia do oczekiwania na ukończenie operacji we/wy.

4. Wywołaj funkcję IoSetCompletionRoutine z IRP, aby górny sterownik mógł, w razie potrzeby, dostarczyć procedurę IoCompletion, aby wykonać następujące czynności:

   • Określ, jak niższy sterownik obsłużył określone żądanie.

   • Po zakończeniu żądanej operacji przez niższy sterownik, ponownie użyj IRP, aby wysłać kolejne żądanie lub usuń IRP utworzone przez sterownik. Sterownik nie może ponownie użyć IRP-ów utworzonych przez IoBuildDeviceIoControlRequest. Aby uzyskać więcej informacji, zobacz Ponowne użycie IRP.

5. Wywołaj usługę IoCallDriver , aby przekazać żądanie do niższego sterownika.

6. Jeśli IoCallDriver zwróci STATUS_PENDING, wywołaj procedurę KeWaitForSingleObject, aby umieścić bieżący wątek w stanie oczekiwania. Sterownik ustawia parametr Object procedury na adres obiektu zdarzenia, który został zainicjowany w wywołaniu keInitializeEvent.

   Uwaga Jeśli sterownik wywołuje KeWaitForSingleObject z parametrem Timeout ustawionym na NULL lub na adres zmiennej, która zawiera wartość niezerową, sterownik musi być uruchomiony na poziomie IRQL <= APC_LEVEL w kontekście wątku niearbitralnym. W przeciwnym razie sterownik musi być uruchomiony przy IRQL <= DISPATCH_LEVEL.

Zdarzenie jest sygnalizowane przez procedurę IoCompletion po zakończeniu żądania IOCTL. Gdy zdarzenie zostanie zasygnalizowane, wątek wznowi wykonywanie.

Ważne Jeśli sterownik przydzieli obiekt zdarzenia jako zmienną lokalną na stosie, sterownik musi wywołać KeWaitForSingleObject z parametrem WaitMode ustawionym na KernelMode. Ta wartość parametru uniemożliwia odstronicowywanie stosu.

Aby uniknąć problemów z synchronizacją i możliwych naruszeń dostępu, parametry kodów kontroli we/wy rzadko zawierają osadzone wskaźniki. Z wyjątkiem niektórych żądań SCSI, bufory w Irp->AssociatedIrp.SystemBuffer, w Irp->MdlAddress oraz w Parameters.DeviceIoControl.Type3InputBuffer w lokalizacji stosu I/O sterownika nie zawierają wskaźników do innych buforów danych ani nie zawierają struktur, które zawierają wskaźniki dla kodów kontrolnych I/O zdefiniowanych przez system. Aby uzyskać więcej informacji na temat sposobu, w jaki bufory danych są używane z IRP zawierającymi kody sterowania we/wy, zobacz Opisy buforów dla kodów sterowania we/wy.

Niemniej jednak para sterowników klasy/portu definiująca wewnętrzne kody sterowania we/wy może przekazać osadzony wskaźnik do pamięci przydzielonej przez sterownik wyższego poziomu do sterownika niższego poziomu. Taka para sterowników klas/portów jest odpowiedzialna za zapewnienie, że spełnione są następujące warunki:

• Tylko jeden sterownik jednocześnie może uzyskiwać dostęp do danych.

• Bufory prywatnych danych są dostępne przez sterownik portu w dowolnym kontekście wątku.

Sterowniki wyświetlania mogą wywoływać funkcję GDI EngDeviceIoControl w celu wysyłania prywatnie zdefiniowanych, specyficznych dla urządzenia żądań sterowania we/wy, a także zdefiniowanych przez system publicznych żądań sterowania we/wy, za pośrednictwem sterownika portów wideo systemu do odpowiednich sterowników miniportów wideo specyficznych dla karty.

Każdy składnik trybu użytkownika pakietu sterowników może wywołać deviceIoControl w celu wysyłania żądań kontroli we/wy do stosu sterowników. Menedżer we/wy tworzy żądanie IRP_MJ_DEVICE_CONTROL i dostarcza je do sterownika najwyższego poziomu.