Summary of driver sys Development

1. Driver Introduction

1. What is the driver?
The external devices of a computer need to exchange data with the computer. How can manufacturers of external devices exchange data between the computer and their own devices? They are reading data from the device to the computer through a driver, in the early days of win3.1, the driver of Win9x was VxD, and the driver of Win NT was KDM. Win2k was uniformly developed into the WDM mode.

1.2.sys File
The sys file is the executable code of the driver. Its extension is. SYS. After the driver is installed, it is saved in the Windows/system32/DRIVERS directory.

For a PNP device, after the device is inserted, the Sys File is loaded to the memory by windows, and the system thread calls the function in sys to communicate with the device.

1.3.inf File
The inf file is a file that must be used to install the device driver. Its extension is. INF. After the driver is installed, it is saved in the Windows/INF directory.

The system uses a text file with an extension of INF to control most of the activities related to driver installation. The inf file should be provided by driver developers along with the driver. The inf file tells the operating system which file needs to be copied to the user's hard disk and which registry key should be added or modified.

INF provides the product ID of the product device, as well as the corresponding sys file name, driver class name, class guid,

1.4.usb-client driver
Host and device, endpoint and pipe

Most of the USB Drivers we develop are USB-client drivers, and most of the system manufacturers have already completed the USB drivers. We are developing drivers for our own devices based on the class drivers, traditionally referred to as USB-client driver, its position in the entire software architecture is as follows:
UHCD--USBD--USB client DRIVER--DLL or app

The USB-client driver still complies with the WDM model and is a WDM driver. To support PNP, you must be very careful with your resources and IRPs and be ready to handle unplugging or inserting devices at any time. Improper power processing will also make the system unable to wake up.

Knowledge needed: WDM, usbdi, our usedevice,
WDM:
Objective: A. Provides interface functions,
B. Supports PNP, power message processing, WMI, and I/O processing,
Usbdi:
Urb, IRP, and other concepts such as interrupt, control, and batch transmission
Our usedevice:
The transmission type and capabilities of our USB devices.

2. WDM Mechanism
Windows 9x and previous versions of VxD, Win NT use the KDM mechanism, and drivers after Win2000 use the WDM mechanism.

2.1.wdm driver layering
Layer chart of the WDM driver:

2.2.pdo and IRP mechanisms
A device uses the same driver. After each layer of the driver is loaded, there is a driver object ).

There is a device chain in the driver object. A node is a device object called PDO. It corresponds to a device and uses the device chain to support multiple devices.

The system uses the IRP (I/O Request package) to communicate with the device. when calling the driver function, it will pass the device object PDO to be operated and the IRP used for communication.

2.3.wdm driver code structure
1. Function composition:
Basic functions: DriverEntry, adddevice, and unload entry functions DriverEntry must be named using DriverEntry and other function names must be registered with the system.
I/O control functions: startio, oninterrupt, dpcforisr, and adaptercontrol.
Distribution Functions: dispatchpnp, dispatchpower, dispatchwmi, dispatchread, and dispatchwrite.
Other functions: deviceioctl, dispatchcreate, and dispatchclose.

In addition to DriverEntry, these functions can be named by themselves and are registered with the system by DriverEntry.

2. Description of necessity:
Required function:
Basic functions: DriverEntry, adddevice,
Distribution Functions: dispatchpnp, dispatchpower, dispatchwmi,
Optional functions:
Function required for processing Request queue: I/O control routine: startio,
If the device needs to interrupt: I/O control routine: oninterrupt, dpcforisr,
Functions required for DMA Operation: I/O control function: adaptercontrol,
Distribution Functions: dispatchread, dispatchwrite,

2. 4. Required Processing
Basic functions: DriverEntry, adddevice,
Distribution Functions: dispatchpnp, dispatchpower, dispatchwmi,

In DriverEntry, you must register the required functions so that the system can call these functions to communicate with the device.

When a new device is inserted, the system calls adddevice. The driver calls iocreatedevice to create a device object, attach it to the device stack, and initialize the flag Member of the device object.

Dispatchpnp: handles the I/O requests sent by the PNP manager with the primary function code irp_mj_pnp to support plug-and-play by devices.

Dispatchpower: processes the I/O requests sent by the power manager with the primary function code irp_mj_pnp to support power management.

Dispatchwmi: processes the I/O request with the primary function code irp_mj_system_control sent by the WMI manager to support WMI (Windows Management Instrumentation). It can monitor the device performance.

For more information, see ddk,d_p2003-050_mbcusb2_trn_wdmstruct_cn.ppt.

3. USB Driver Interface

3.1.usb driver and urb
In this UHCD--USBD--USB client DRIVER--DLL or app structure, usbd wraps the USB port chip drive uhcd to provide more convenient features so that other device drivers can simply take advantage of these features.

The function provided by usbd is called USB di (usbd interface). It mainly uses urb (USB request block) to put urb into IRP (you can assign IRP by yourself) and pass it to usbd, USB devices are operated by usbd.

3.2.urb details
Read the DDK help.

3. Common functions
Usbbuildvendorrequest, usbbuildgetdescriptorrequest, usbbuildselectconfigurationrequest, usbd_parseconfigurationdescriptorex, usbd_createconfigurationrequestex, usbd_parsedescriptors

4. Our devices

Our devices have a control pipeline and two bulk read and write pipelines (both of their own commands are completed through read and write). It supports USB2.0 and supports standard USB requests.

5. sys Development

5. 1. install and configure the development environment
1. Make sure you have installed visual c ++,
2. Install the 2000 DDK. After the 2000 DDK is successfully installed, the project "Development Kits"-> "Windows 2000 DDK" should be included in "start"> "program. (Be sure to install the VC before installing the DDK. This order must not be reversed !!)

Set the ddkroot environment variable to the base Directory of Windows 2000 DDK. If not, you must manually configure it. Set this environment variable in the "advanced" tab environment variable editor of the "System" attribute of the control panel. For example, if the installation path of DDK is E: winddk3790, the variable "DDK root" is created and the value is E: winddk3790.

. Create an INF file
The system uses a text file with an extension of INF to control most of the activities related to driver installation. The inf file should be provided by driver developers along with the driver. The inf file tells the operating system which file needs to be copied to the user's hard disk and which registry key should be added or modified.

The inf file contains segments enclosed by square brackets. Most of the segments contain a series of commands in the form of keyword = value. Example: [version] Signature = "$ Chicago $" class = uusbd classguid = B51CA6BA-E750-4dff-9CDE-6AA963B17052 {} provider = % leading % driverver = 08/27/2001, 0.1.0.1

For more information, see d_p2003-050_mbcusb2_trn_infstruct_cn.ppt.

. Compile and compile the driver
1. makefile, 2. Sources File

The content of makefile is:
# Do not edit this file !!! Edit. sources. if you want to add a new source # file to this component. this file merely indirects to the real make file # that is shared by all the driver components of the Windows nt ddk #! Include $ (ntmakeenv) makefile. Def

Sources:
Targetname = hellowdm targettype = driver drivertype = WDM targetpath = OBJ? Required des = $ (basedir) Inc; $ (basedir) incddk; targetlibs = $ (basedir) lib * freeusbd. Lib? Sources = hellowdm. CPP this file specifies the generated driver target name, the location where the OBJ file is stored, the location of the Lib file, and the compiled source file object. It is worth noting that, there must be no spaces before and after "=". Otherwise, an error will occur during compilation.

Compile:
Select the compiling environment from the Start Menu, for example, Windows 2000 checked build environment.exe. It reads the configuration of the program to be compiled from the configuration file sources, including the source file and target file, obtain the address of the referenced file from the environment variable include, and then call the compilation linker to compile the link. Compile the generated log file: The warning build. Err Link error encountered in the command line build. WRN link executed in the build. Log Link

. Driver Installation and debugging
Win2000 and later use the *. inf file to control most of the activities related to driver installation. The inf file is provided by the driver developer along with the driver. Control Panel-> Add new hardware, select another device from the hardware list, click Install from a floppy disk, Click Browse, find the folder where *. inf is located, and click OK. Next, click Next. After installation, the driver appears in device management.

Debugging method:
Dbuplint (),
Systemdump,
Assert (),
Windbg tracking, you can set a hard breakpoint (insert dbgbreakpoint () function) and a soft breakpoint (after running to a hard breakpoint, open the source file in the windbg program and set a soft breakpoint)

Detailed information, check d_p2003-050_mbcusb2_trn_wdmdevelop?cn.ppt, D_P2003-050_MBCUSB2_TRN_WDMDEVELOP2_CN.ppt, Machinery Industry Press, the Windows2000 device driver program design refers to the south, Appendix A driver debugging environment, Appendix B fault check code

6. Experience and Lessons Learned

6. 1. Check your code carefully
The driver runs under the kernelmodel, which is different from the application. If your code has any problems, you can see a blue system crash screen or the system restarts directly,

. Necessity of machine debugging
Because the code may inevitably have errors, it is necessary to have a debugging machine. Otherwise, you will waste most of your time waiting for shutdown and reset on the computer, the progress of work is crawling like a snail bait.

Pay attention to your dbug information, especially dbgbreakpoint. If your machine is not in debugging mode, the breakpoint will suspend your system, black screen, and no operation can be performed, no display is displayed.

. Be cautious and conscientious
Be careful when handling every IRP and any of your resources. It is best to have a means to determine whether they are correctly handled and used, such as adding symbolic debugging information and using counting. Otherwise, you will spend a lot of time discovering these subtle and fatal errors.