Electrical computers and digital data processing systems: input/ – Input/output data processing – Peripheral adapting
Reexamination Certificate
2002-10-01
2004-11-16
Huynh, Kim (Department: 2182)
Electrical computers and digital data processing systems: input/
Input/output data processing
Peripheral adapting
C710S036000, C719S321000, C713S152000
Reexamination Certificate
active
06820146
ABSTRACT:
BACKGROUND OF THE INVENTION
The WINDOWS driver model (WDM) is a driver technology developed by the MICROSOFT Corporation that supports drivers which are compatible for WINDOWS 98, 2000, ME AND XP. WDM allots some of the work of the device driver to portions of the code that are integrated into the operating system. These portions of code handle low-level buffer management, including direct memory access (DMA) and plug-n-play (PnP) device enumeration.
A DRIVER_OBJECT data structure, corresponding to a single loaded device driver according to WDM, contains a table of function pointers referred to as the dispatch table. The numerical values used to index into the table, namely to find specific functions, are called function codes and are given symbolic names that refer to a type of input/output (IO) such as READ and WRITE or refer to other requests such as CREATE, DEVICE_CONTROL and PnP.
The function located in the table at the corresponding index is expected to implement logic for carrying out such an IO request. The operating system delivers IO request packets (IRPs) to these functions. The operating system also, for each IRP, identifies the device for which the request is intended, in the form of a DEVICE_OBJECT data structure. Such a DEVICE_OBJECT was previously initialized by the driver and represents a single device handled (driven) by the driver. A driver defines its own dispatch functions and inserts them into the dispatch table in its DRIVER_OBJECT at the time the driver initializes itself.
A device node (devnode) is the context (set of data structures and configuration storage) representing a single device within a WDM operating system. If the device is active (connected and enabled for use), then (in the kernel) such a context will include a stack of device object structures, typically one per driver in the layered driver architecture for that type of device. By convention, stacks are said to be built from the bottom up (with the device being below the bottom of the stack) and dismantled from the top down. It is noted that being lower in the stack connotes being closer in terms of directness of communication to the device, while higher connotes being farther away.
Device objects (DOs) in the stack fall into one of three categories. The bottom-most device object is created by the driver for the bus that provides access to the device and is called the physical device object (PDO). The bus driver provides raw communications capability to the device, but little in the way of higher-level device-specific functionality.
Typically a function device object (FDO) is created by a driver which provides access to device-specific and higher-level capabilities of the device. An FDO will be located higher in the device stack than a PDO. In addition to the PDO and FDO, there may optionally be one or more filter device objects (FiDOs). Such FiDOs may be located in the device stack between the PDO and FDO, or above the FDO.
FIG. 1
is a software block diagram that illustrates the layered relationships of objects according to the WDM architecture. Such a WDM architecture
100
includes a device
102
and a bus
104
to which the device
102
is physically connected. A host computing device
105
is also connected to the bus
104
. The host
105
includes a variety of software such as an enumerator of bus devices (hereafter DO enumerator)
110
, application
106
, a PnP manager
108
, a bus function driver
112
, and a device function driver
116
. It is noted that there also may be one more lower filter drivers and one or more upper filter drivers or none at all.
When a device
102
is connected to a bus
104
, the bus driver
112
notifies the operating system of a change on the bus. The operating system, i.e., the PnP manager
108
, issues a query to the bus
104
via an IRP sent downward in the layered architecture instructing the bus function driver
112
to discover (or enumerate) the devices currently connected to the bus
104
. In response to this query, the bus function driver
112
generates PDOs for any newly-connected/discovered devices and provides a set of pointers to the newly-generated PDOs as well as previously-existing PDOs (corresponding to previously albeit currently connected devices). Strictly speaking, the set of DOs represented by the returned pointers are not PDOs until the operating system, namely the PnP manager, examines the set and becomes aware of these DOs.
The PnP manager
108
locates and loads into volatile memory (if not already loaded) the function driver and any filter drivers for the newly-connected devices. It then gives each filter driver and/or function driver an opportunity to create and attach corresponding FiDOs or FDOs to the stacks rooted in the new PDOs, respectively. Ultimately, an application
106
can access a device
102
i.e., consume the functional abilities of the device
102
, by passing IRPs through the stack.
When the device is to be disconnected or disabled, the stack must be destroyed. From the top down, under the coordination of the PnP manager
108
, each driver detaches its device object from the stack and deletes it.
More detail is provided in
FIG. 5
, which is a sequence diagram according to the unified modeling language (UML) principles. The sequence
500
in
FIG. 5
depicts the various interactions between the device
102
, the bus
104
, the bus driver
112
, the PnP manager
108
, the device lower filter driver
114
, the device function driver
116
, the device upper filter driver
118
and the application
106
. The device
102
connects to the bus
104
at message
518
. The bus
104
then notifies the bus driver
112
of a change in connected devices at message
520
. The bus driver
112
notifies the PnP manager
108
of a change in connected devices at message
522
. The PnP manager
108
queries the bus
104
to obtain a set of connected devices via message
524
, e.g., an IRP, to the bus driver
112
. If not already known by the bus driver
112
, then the bus driver
112
queries the bus
104
to discover the connected devices via the query message call
526
. The bus driver
112
creates PDOs for newly discovered devices and returns pointers to (addresses of) all PDOs representing devices connected to the bus to the PnP manager
528
.
Upon receiving the set of PDOs, the PnP manager enters a loop
530
by which it handles any PDO in the set of which the PnP manager was not previously aware. At message
532
, the PnP manager passes one of the PDOs to any device lower filter drivers
114
that might be present. In response, each device lower filter driver attaches a new FiDO to the corresponding stack
128
(see legend
534
in FIG.
5
). Then the PnP manager
108
passes the PDO to the device function driver
116
, at message
536
.
In response, the device function driver
116
attaches a new, named FDO to the device stack
128
and correspondingly registers device-class interfaces (see legend
538
) by which consumers can access the device stack. Next, the PnP manager
108
passes the PDO to any device upper filter drivers
118
, at message
540
. In response, each device upper filter driver
118
attaches a new FiDO
126
to the device stack
128
(see legend
542
). Lastly, the PnP, manager
108
notifies applications
106
of the availability of the new device
102
, at message
544
. In response, the applications
106
may utilize (consume the services of) the device
102
(see legend
546
).
Returning to
FIG. 1
, a stack
134
for the bus
104
is depicted. The stack
134
includes a PDO for the bus
130
(generated by the bus DO enumerator
110
) and a bus FDO
132
(generated by the bus function driver
112
).
A stack
128
for the device
102
has also been created. The stack
128
includes a PDO
120
(generated by the bus function driver
112
), and (possibly) a FiDO
122
(generated by the optional device lower filter driver
114
, if present), an FDO
124
(generated by the device function driver
116
) and (possibly) a FiDO
126
(generated by the device upper filter driver
118
, if present). In
LandOfFree
Filter driver for blocking access by host to devices does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Filter driver for blocking access by host to devices, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Filter driver for blocking access by host to devices will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3291153