2--Standard Model of file system driven programming basic articles

Second, the Standard Model

WDM uses the Structured programming method, the execution efficiency is very high, but the writing efficiency is low, this is also the driverstudio to develop the important reason. Just as mastering the COM principle, using ATL to grasp the essence of the truth, the reader needs to endure the memory of a lot of basic knowledge of the "pain", and temporarily give up the shortcut to write the driver.

Some of the following illustrations are slightly stale, but they are sufficient to illustrate the problem.

Although the drivers are grouped into multiple categories (Figure 1-4), they contain the same basic content (Figure 1-5). Each driver enters from the initialization program, DriverEntry a dispatch routine dispatchxxx a specific command (which we might call an IRP) that may be resolved at the dispatch Chengri, or it may be addressed to other parts of the driver. If driver a itself is unable to handle this IRP command, it will need to pass the IRP to a lower drive B, which is handled by them, at which point driver a may be asleep while waiting for the IRP to complete, or continue to process the new IRP, Until the lower drive B notification (or Wake up and notify by some mechanism) a the IRP has been disposed of, at which point A will return the result (which we call NTSTATUS) to the originator who originally distributed the IRP. This is a simplified process by which the driver processes the IRP.

We mentioned that the driver is the concept of layering, so how to understand the concept of layering? Please look at the diagram:

Quote 1 for the exact words: The WDM model uses a hierarchy like Figure 2-1. The left side of the diagram is a stack of device objects. A device object is a data structure that the system creates to help software manage hardware. A physical hardware can have multiple such data structures. The device object that is at the bottom of the stack is called a physical device object (physical device object), or simply PDO. Somewhere in the middle of the device object stack is an object called a functional device object (functional device object), or simply FDO. There will also be some filter device objects (Filter device object) above and below the FDO. The filter device object located above the FDO is called the upper filter, and the filter device object located under FDO (but still above PDO) is called the lower filter.

An IRP initiated by some guy (possibly in user mode or system kernel component) from the upper filter driver has been downstream, passed to the bus driver processing, and then step back to the top, the final initiator of the results of processing.

In general, the IRP may not need to be passed to the bus driver to be disposed of, but if everyone does not know this IRP, they have to step down, if there is a disruptive driver mixed in, intercepted the IRP, light loss of user information, restart, panic, Heavy causes data clutter in the system area, and you have nothing to do but reinstall the operating system. This shows that we do not require the driver "has the ideal", but must be "disciplined", each driver must be in strict accordance with the specifications of the writing code, which requires programmers have a higher quality.

Let's take a look at the most basic Standard model in driver programming, which does not solve all the programming requirements, and it will vary depending on your needs. Let's take a look at the "basic formula" in this driver programming:

IO Manager, it should be understood as the initiator of the IRP, may be John, or it may be dick, not a fixed component. This model shows the cooperation and division of the parts in a single driver, noting that it is a cyclical process, and that the initiator is the same as the final recipient, the so-called "where it comes from and where it goes". If our programming does not involve real hardware, the startio routines, interrupt service routine ISR, and DPC routines may not exist. Please refer to chapter fifth of data 1 for specific functions of each component.