Книга: Writing Windows WDM Device Drivers

Сноски из книги

There are several other IRPs which are only generated by the kernel in response to kernel related events. For example, when the system decides to powers down, a Power IRP is sent all drivers.

In NT and W2000 you can use the QueryDosDevice Win32 function to obtain a list of all symbolic links. I am not sure how useful this list is.

You are also supposed to queue IRPs that arrive while your device is sleeping. The simple solution to this problem is to wake up your device when an IRP arrives.

I used this approach when writing this book. My initial contents were completely different from the end result, and I rewrote these initial chapters after the rest of the book was complete.

If a file system driver is fetching a page back into memory then the IRQL may be APC_LEVEL.

NT 3.51 drivers should use zone buffers, which are now obsolete.

Actually, the kernel stack may be paged if a driver issues a user-mode wait (e.g. in KeWaitForSingleObject).

You will probably need to ensure that the Windows 98 environment space size is at least 2048 for device driver development.

The PHDIo and Wdm3 drivers are not included in the compilation list as they do not compile in Windows 98.

Be careful if initializing strings in paged code segments or code segments that are discarded after initialization. The Buffer data has the attributes of the underlying code segment and so may not be available when you want to access it. Chapter 14 gives an example in which I initially got this wrong. 

If you call IoAttachDeviceToDeviceStack at a higher IRQL, your driver may crash. 

If you are only compiling in W2000, you can include initguid.h instead.

CancelIo first became available in NT 4 and W98.

Blocking in dispatch routines is not recommended as it defeats the purpose of overlapped operations.

If the driver processes IRPs one by one, it could store this information in its device extension.

The first driver must disable its device interrupts, reprogram its hardware, and then enable interrupts again.

Both FDOs and PDOs use exactly the same DEVICE_OBJECT structure.

I don't know for sure because I don't know how they work. And I don't care!

For ACPI systems, the ACPI bus driver implements the root device.

However, note that the USB OpenHCI driver accesses hardware directly, once it has its configuration information from the PCI bus driver.

Non-WDM NT style drivers may use more than one full resource descriptor.

Obviously, this may well change in 64-bit systems.

BROADCAST_QUERY_DENY has a value of 0x424D5144, ASCII "BMQD", which I presume stands for Broadcast Message Query Deny!

I think PDOs must be created with FILE_AUTOGENERATED_DEVICE_NAME as the DeviceCharacteristics parameter to IoCreateDevice. 

Note that there are various optional elements to the ACPI, but the PC99 specification makes several of these mandatory.

I think that this is because you are already processing a Power IRP and only one such IRP can be active at a time.

See the article on the Microsoft web site entitled "USB Plug and Play IDs and Selecting Device Drivers to Load", http://www.microsoft.com/hwdev/busbios/usbpnp.htm.

NT style drivers may well work in Windows 98, as well. See the next section for details.

NT 4 driver writers can write an OEMSETUP.INF or TXTSETUP.OEM script to install their drivers. See the NT 4 DDK for details.

In Windows 98, select the Control Panel "Add/Remove Programs" applet. Click the Windows Setup tab. Highlight the Internet Tools options. Click on Details. Check the "Web-based Enterprise Mgmt" box. Click OK to proceed with the installation. You will need the WBEM core kit and possibly other components for NT 4 and Windows 95.

Since writing this chapter, the test driver DebugPrint code has changed from C++ to C. The code on the book software disk is slightly different from the code printed in this chapter, though they are functionally identical. 

I.e., soon after the Gregorian calendar was introduced in 1582.

The NT 4 DDK wrongly states that RemoveHeadList and RemoveTailList return NULL if the list is empty.

See Chapter 19 for the best way to talk to a parallel port in NT and W2000.

You might want to add another IOCTL that tells you which resources a device is using, so applications know which WdmIo device to use.

Or for that matter, an application must not fire off several overlapped requests at the same time.

If there is more than one WdmIo device, each device has a device queue that can be processed simultaneously by WdmIoStartIo.

Note that the IoStartNextPacket implementation will, in fact, call WdmIoStartIo recursively (if there is another IRP in the queue). In the worst case, this recursive technique could overflow the kernel stack. One of the DDK examples shows a way of avoiding this problem by not queuing an IRP if the queue is "full". 

At the last moment, I have moved this code back into WdmIoStartIo. RunCmds may not run at DIRQL and it is incorrect to allocate nonpaged memory above DISPATCH_LEVEL. 

In fact, the I/O Manager could work out if an IRP is in the device queue.

You may also decide to queue IRPs while a device is asleep. The example drivers in this book opt to wake up the device when an I/O request arrives.

Note that the interrupt level is not the same as the IRQ number. IRQ7 has interrupt level 20.

Actually, the commands could take a long time to run if the Win32 application includes large delay commands. However, moving the command processing to the DPC would not help, as a Critical section routine would have to be run, bringing the IRQL back up the DIRQL.

The LockDevice and UnlockDevice routines are still used and so have been moved from Pnp.cpp into Init.cpp. 

I do not know where they go in Windows 98.

You can also access the HID class driver in a user-mode client application.

The only alternative is to remove the parport, parallel, and parvdm drivers, which would stop any existing parallel port access. 

See Chapter 23 for details of IoGetDeviceObjectPointer. 

Note that there are two uses of the word "class". Device drivers use the Windows USB class drivers to get access to the USB system. Each USB device can be categorized as a basic USB device, or as belonging to a class of USB devices such as HID, printer, etc.

The Windows 2000 DDK defines the Interface power descriptor structure. However, it is not apparent whether this information is used by the system USB class drivers.

Presumably to avoid unnecessary copying of large buffers.

Unlike a processor execution stack, there is nothing wrong with altering the next item down the stack.

The UsbGetIdleRate routine shows how to read the idle rate. 

 Note that the call to UsbBuildInterruptOrBulkTransferRequest must be in the loop for it to work in W2000. 

Using KeQuerySystemTime is less efficient. 

In Windows 98, I found that I could not type on my HID keyboard after a reboot.

This is called Draft#4 compliance. An older Draft#3-compliant device returns the HID descriptor after the endpoint descriptors.

Kernel mode HID clients can get and set the ring buffer size using two IOCTLs.

The device to which you are connecting must accept a Create IRP call with an empty filename.

So far, we have not considered how the kernel calls our driver. However, to be most efficient, we should not block while processing an IRP for very long. Blocking in a Power or PnP IRP handler or a system thread is fine.

Оглавление книги