i/o file system filter driver for windows nt

I/O File System Filter Driver For Windows NT

CALIFORNIA SOFTWARE LABS

R E A L I Z E Y O U R I D E A S

California Software Labs6800 Koll Center Parkway,

Suite 100 Pleasanton CA 94566, USA.

Phone (925) 249 3000 Fax (925) 426 2556

[email protected]://www.cswl.com

mailto:[email protected]

http://www.cswl.com/

www.cswl.com

CSWL Inc, Pleasanton, California - 2 -

I/O File System Filter Driver For Windows NT

A Technical Report Technical Expertise Level : Intermediate Requires knowledge of : Device drivers and basic knowledge of Windows NT architecture

INDEX

INTRODUCTION............................................................................................................. 4

WINDOWS NT DRIVER MODEL ................................................................................ 4

INTERMEDIATE DRIVERS.......................................................................................... 5

FILTER DRIVERS........................................................................................................... 6

WHEN CAN I USE A FILTER DRIVER? .................................................................... 6

HOW ARE FILTER DRIVERS ATTACHED TO AN UNDERLYING DRIVER.... 7

CONTROLLING THE DRIVER FROM AN APPLICATION................................... 8

WHAT ARE FILE SYSTEM DRIVERS?.................................................................... 10

HOW FILE SYSTEM DRIVERS DIFFER FROM OTHER WINDOWS NT DRIVERS?....................................................................................................................... 11

OUTLINE OF THE FILE SYSTEM DRIVER MODEL ........................................... 11

CONTROL FLOW IN THE DRIVER MODEL ......................................................... 12

THREAD CONTEXT MANAGEMENT ..................................................................... 14

WHY DO WE NEED GUARANTEED I/O?................................................................ 16

COMPUTING DISK BANDWIDTH............................................................................ 16

CHALLENGES IN PROVIDING GUARANTEED I/O............................................. 17

IMPLEMENTED SOLUTION...................................................................................... 19

HOW FILTER GETS CONTROL................................................................................ 20

WHAT THE FILTER DOES?....................................................................................... 22

RESERVATION MANAGER: ............................................................................................. 23 COLLECTOR: .................................................................................................................. 24 SCHEDULER: .................................................................................................................. 24 DISPATCHER: ................................................................................................................. 25

www.cswl.com


SCHEDULING LOGIC OF THE FILTER USING TIME STAMPS....................... 25

INSTALLATION, TESTING AND DEBUGGING .................................................... 26 INSTALLATION: .............................................................................................................. 26 TESTING:........................................................................................................................ 27 DEBUGGING: .................................................................................................................. 28

WHERE TO GO FROM HERE?.................................................................................. 29

REFERENCES................................................................................................................ 30

www.cswl.com


Most of the modern world applications require high performance and are greatly

dependent on the transfer rate of data to and from the disk. But Windows NT, the

mostly widely used operating system in the industry does not provide any

semblance of disk guarantee to the applications. It would require a specially written

device driver to incorporate this feature on the Windows NT operating system.

INTRODUCTION

Most of the modern world applications require high performance and are greatly

dependent on the transfer rate of data to and from the disk. But Windows NT, the

mostly widely used operating system in the industry does not provide any

semblance of disk guarantee to the applications. It would require a specially written

device driver to incorporate this feature on the Windows NT operating system.

Windows NT Driver Model

As it is shown in the diagram, NT includes a number of kernel mode components

with well-defined functionality isolated in each component. The File System,

intermediate and other device drivers are shown integrated with the NT I/O

Manager. The NT I/O Manager presents a consistent interface to all the kernel-

mode drivers, including device, intermediate and file system drivers. The I/O

Manager exports system services, which user mode protected subsystems call to

carry out I/O operations on behalf of their applications. These system services

include the Configuration Manager, Memory Manager, Object Manager and the

Security Reference Monitor. All I/O requests to NT drivers are sent as I/O request

packets (IRPs). The I/O Manager intercepts these calls, sets up one or more Irps,

and routes them through to the respective drivers.

The Windows NT driver architecture uses an entry point model, in which the I/O

Manager calls a particular routine in a driver when it wants the driver to perform a

particular function. The I/O Manager passes a specific set of parameters to the

www.cswl.com


driver to enable it to perform the requested function. The function that is first called

when a driver is loaded is the DriverEntry. The driver performs initialization for

itself and any device it controls. The driver can have up to one Dispatch entry point

for each major I/O function that it supports. These Dispatch entry points are called

by the I/O Manager to request the driver to initiate a particular I/O operation. E.g.

The driver can have a Dispatch entry point for a read operation as DispatchRead (..)

which the I/O Manager calls when it needs to read from the particular device.

Windows NT allows several driver layers to exist between an application and a

piece of hardware. Thus drivers are grouped together in stacks that work together to

completely process a request targeted at a particular device object.

Windows NT uses a layered driver model to process I/O requests. In this model,

drivers are organized into stacks. Each driver in a stack is responsible for

processing the part of the request that it can handle, if any. If the request cannot be

completed, information for the lower driver in the stack is set up and the request is

passed along to that driver.

This layered driver model allows functionality to be dynamically added to a driver

stack. It also allows each driver to specialize in a particular type of function and

decouples it from having to know about other drivers.

Intermediate Drivers

Intermediate drivers form the middle layer of the driver hierarchy. Intermediate

drivers provide value-added feature or class processing for devices. Intermediate

drivers rely upon the device drivers below them in the NT driver hierarchy for

access to a physical device.

www.cswl.com


Filter Drivers

A Filter Driver is a special type of layered driver. What sets a filter driver apart

from the layered driver is that it is invisible. They attach themselves to any other

driver and intercept requests directed at the lower driver’s Device objects. It is

developed primarily to allow the addition of new functionality beyond what is

currently available. The filter driver may either use the services of the original

target of the I/O request, or use the services of other kernel-mode drivers to provide

value-added functionality.

When can I use a filter driver?

Filter Drivers are used to add features to a device without modifying the underlying

device driver or the programs that use the device. Filters allow us to modify some

aspects of an existing driver’s behavior without re-writing the underlying driver.

Let me explain the necessity of a filter driver with an example.

Consider a case where it is decided to design and implement on-line encryption /

decryption functionality on an existing Windows NT file system. At present, the

operating system does not provide any such functionality. In such a situation, it

would not be cost effective to design our own file system implementation to store

encrypted files. Besides, users would wish to continue using the existing native

Windows file system. This is one situation where a filter driver comes to the rescue

of the designer. The optimal solution for this problem would be to design a filter

driver that would perform the encryption/decryption processing on the data. The

filter driver could also use the services provided by the existing drivers on the

system. Hence it can use the services of the file system driver and the disk drivers

to manage transfer of data on the secondary storage devices.

www.cswl.com


How are Filter Drivers attached to an underlying Driver

The Windows NT I/O Manager includes the capability for one kernel mode driver

to “attach” one of its Device Objects to a Device Object created by a different

driver. This is accomplished by making a call to an I/O Manager routine,

IoAttachDeviceByPointer (). This routine attaches the filter driver’s device object

to a target device object. The following are the basic steps that the driver must

perform to successfully attach to a target device object: -

• Get a pointer to the target device object.

• Create a device object that will be used in the attach operation.

• Ensure that the driver is set up to process the I/O requests, originally

directed to the target device object, that will be sent to it instead. I.e. the

driver needs to have all the Dispatch entry points as that of the original

driver so that it can redirect the request to the original driver.

• Ensure that the fields in the device object are set correctly to maintain

complete transparency to the modules that normally invoke the target

driver.

• Request the I/O Manager to create an attachment between the two device

objects.

Once the attach operation has been completed, the I/O Manager will begin

redirecting I/O requests to the device object of the filter driver instead of

forwarding them to the driver managing the target device object.

www.cswl.com


The result of this is that IRPs destined for the driver associated with the original

Device Object will be sent to the driver associated with the “attached” Device

Object. This attached driver is the Filter Driver. This filter driver can then examine,

modify, complete, or pass along the IRPs it receives to the original driver.

Controlling the driver from an application

Each driver specific I/O stack location in every irp has a major function code

(IRP_MJ_XX) that tells the driver what operation it or the underlying device driver

should carry out to satisfy the I/O request. Apart from the standard function codes

such as create, read, write etc., a driver can also define a set of specialized

functions. These may be used to perform certain driver specific operations or to

provide a private communication mechanism between the driver and an application.

Such device specific requests are specified using the

IRP_MJ_DEVICE_CONTROL major function code.

IRP_MJ_DEVICE_CONTROL allows us to define functions that are available to

user-mode clients through the Win 32 DeviceIoControl function. The device

www.cswl.com


control function to be performed is indicated by an I/O control code (or IOCTL),

that is passed as part of the request.

Windows NT provides a macro, CTL_CODE that defines such custom control

codes. This allows a single header file, defining the custom IOCTLs that a driver

implement, to be shared by a driver and any application programs that may issue

IOCTL requests to the driver. The CTL_CODE macro takes the following

arguments:

CTL_CODE (DeviceType, Function, Method, Access)

DeviceType:

The DeviceType argument for the CTL_CODE macro is a value (of type

DEVICE_TYPE) that indicates the category of device to which a given I/O control

code belongs.

Function:

The Function argument of the CTL_CODE macro is a value, unique within the

driver, which is associated with a particular function to be performed.

Method:

The Method argument indicates to the I/O Manager how the data buffers supplied

with this request are to be described.

Access:

The Access argument to the CTL_CODE macro indicates the type of access that

must have been requested (and granted).

In many situations, additional arguments may have to be passed on to the driver

from the user application or vice-versa. The Win 32 DeviceIoControl function lets

www.cswl.com


the user specify a pair of input and output buffer addresses along with the IOCTL

code.

DeviceIoControl function prototype

BOOL DeviceIoControl (

Handle hDevice,

DWORD dwIoControlCode, //handle to device of interest

LPVOID lpInBuffer, //control code of operation to perform

DWORD nInBufferSize, //pointer to buffer supplying input data

LPVOID lpOutBuffer, //size of input buffer

DWORD nOutBufferSize, //pointer to buffer receiving output data

LPDWORD lpBytesReturned, //size of output buffer

LPOVRLAPPED lpOverlapped //pointer to overlapped structure

);

It's a good idea to write a separate header file for the control code definitions and

include it in both the driver and the user mode programs that issue Win 32

DeviceIoControl calls to the driver.

What are File System Drivers?

A file system driver is a component of the storage management subsystem. It

provides the means for users to store information and retrieve it from nonvolatile

media such as disks or tapes. File System Drivers are tightly integrated with the NT

Memory Manager and Cache Manager subsystems.

www.cswl.com


How File System Drivers differ from other Windows NT Drivers?

There are a few characteristics that set a File System Driver apart from other device

drivers. These differences allow the file system drivers to fulfill their special roles

in Windows NT systems. Some of these characteristics include:

• File System Drivers are guaranteed to be called in the context of the

requesting thread.

• File System Drivers are tightly integrated with the NT Memory Manager

and the Cache Manager subsystems.

• File System Drivers are closely intertwined with the NT I/O and Object

Managers.

• Only File System Drivers implement Fast I/O entry points for read and

write operations. The NT I/O Manager will not call the read or write Fast

I/O entry points of intermediate or other device drivers

Outline of the file system driver model

The file system driver receives requests to open, create, read, write and close files

on disks. These requests typically originate in the user process and are dispatched

to the file system via the I/O subsystem manager. Fig 1 describes how a local file

system driver provides services to a user thread.

When a user thread issues an I/O function call, the Win32 subsystem invokes the

corresponding service call to request the operation on behalf of the caller. At this

point the CPU switches to kernel-mode privilege level. The I/O Manager builds an

I/O Request Packet (Irp) describing the I/O request and calls the File System Driver

at the appropriate dispatch entry point. The File System Driver performs

appropriate processing and returns the results to the I/O Manager, which in turn

returns them to the Win32 subsystem (the privilege level switches back to user-

www.cswl.com


mode), and the Win32 subsystem eventually returns the results to the requesting

process.

Control flow in the driver model

www.cswl.com


Probably the single greatest differentiating factor between File System Drivers and

other drivers is that FSDs tightly integrate with the Windows NT Memory Manager

and the Cache Manager subsystems.

Typically, I/O requests for a file are conveyed by the I/O Manager to the file

system driver using I/O Request Packets (IRPs). However, the overhead associated

with the creation, completion and destruction of Irps is sometimes an inhibitor of

good performance. Also, if the Cache Manager caches the data, it is possible that

such data could be directly obtained from the system cache by directly issuing a

request to the Cache Manager instead of getting it through Irps. The desire to

www.cswl.com


achieve better system performance led to the creation of Fast I/O method for

obtaining cached data in the Windows NT environment.

Fast I/O is only performed if the file stream is cached and it is always a

synchronous operation. An interesting point to note is that if data transfer is not

possible using the Fast i/o path for a specific operation on a file stream, the I/O

Manager simply resorts to using the standard IRP method to retry the operation.

Whenever, the I/O Manager receives a user request to access an open file stream,

the I/O Manager invokes the Fast I/O entry point. The Fast I/O entry point is of

type BOOLEAN. This allows the FSD to inform the I/O Manager about whether it

was able to process the request. If the FSD was able to completely process the

request in its Fast I/O routine, the FSD returns TRUE as the status of the Fast I/O

routine. This results in the I/O Manager completing the request back to the

requestor. If the FSD could not completely process the request, it returns FALSE

from its Fast I/O routine. In this case, the I/O Manager builds an IRP that describes

the I/O request and calls the FSD at the appropriate dispatch entry point. The FSD

then retrieves the data from the disk.

Thread context management

File System Drivers (FSDs) are always logically located at the top of a Windows

NT stack of drivers. Thus a file system driver will always be called in the context

of the thread making the request. This guarantee makes it possible for file system

drivers to use Neither I/O for describing requests. Implementing Neither I/O allows

a file system driver to manipulate data by using the requestor’s virtual address.

Thus, I/O requests for FSDs must be passed to the FSD in the context of the thread

originally initiating the request. If a filter driver changes the context of the request,

by sending a request off to be processed by a worker thread, the FSD will fail to

work as the address it references in the user space is not valid in this arbitrary

thread context.

www.cswl.com


This will result in a page fault, as the FSD will be referring to non-existent

memory. To avoid this catastrophe, the filter driver must ensure that the kernel

virtual address for the requestor’s buffer is usable in an arbitrary thread context.

This is accomplished by changing the buffering method from Neither I/O to Direct

I/O. In the case of Direct I/O; the I/O Manager automatically builds a Memory

Descriptor List (MDL) describing the caller’s buffer. MDL is a structure that keeps

track of the physical pages associated with a virtual buffer. The MDL consists of a

header describing the virtual buffer, followed by an array that lists the physical

pages associated with the buffer. Given, a virtual address within the buffer, it is

possible to determine the corresponding physical page.

Therefore if a filter decides that it requires the requestor’s buffer to be usable in an

arbitrary thread context, it is required to perform the following steps:

• Create an MDL to describe the requestor’s buffer.

• Check the pages that comprise the buffer for accessibility and lock the

pages into physical memory.

www.cswl.com


• Map the requestor’s buffer described by the MDL into kernel virtual

address space.

The pointer to the MDL is supplied to the FSD in the IRP (at IrpàMdlAddress).

Why do we need guaranteed I/O?

Many real time applications may require atleast a bare minimum of the disk

bandwidth to function properly. For example, Media players always require a

minimum disk bandwidth for it to function properly (ensure a smooth transfer

between the frames) failing which the transition between frames will be abrupt.

But Windows NT does not provide any native support for any such guarantees on

disk I/O. The bandwidth enjoyed by an application is not consistent in most cases

and it tends to reduce with the number of disk hungry applications. Hence there is

no guarantee that the applications continue to get their required bandwidth. It

would require a specially written driver to incorporate this feature on the Windows

NT operating system.

Computing disk bandwidth

Disk bandwidth is defined as the number of bytes that can be accessed from a disk

in a time quantum. The bandwidth of the disk is calibrated by timing all the Irps

that make disk access.

The filter driver determines the time taken to service these Irps by setting a

“Completion Routine” before dispatching them to the file system driver. Once this

completion routine is set the filter is notified by the I/O Manager when the Irp is

completed. This is done for all the Irps that read from the disk so that any

differences in the bandwidth calculations are averaged out over a period of time.

www.cswl.com


Challenges in providing guaranteed I/O

The whole idea of trying to guarantee I/O requests in Windows NT evolves around

the estimation of disk bandwidth. Bandwidth, here is the number of bytes accessed

from the disk in a time quantum. The primary challenge in providing guaranteed

I/O is devising a reliable mechanism to estimate or predict the time taken to service

a given number of bytes by the file system driver. There are a number of factors

that affect the time taken to service an IRP.

The following are a few main factors among them:

Bandwidth Variation

Guaranteeing I/O for an application greatly depends on the estimation of disk

bandwidth. The bandwidth of the disk is not a constant value, but keeps varying

i.e., the time taken to service "n" bytes is not always a constant. Thus it may be

inferred that the number of bytes that are accessed from the disk is not the only

criterion deciding the disk bandwidth. A host of other factors may also play a role

in deciding the bandwidth. Thus a proper and reliable estimate of the bandwidth

can be obtained only after a considerable number of reads are timed. This may

average out the differences in estimating the bandwidth.

The physical file stream (FAT or NTFS) plays a role in how requests are

processed:

The File system drivers corresponding to the FAT or the NTFS file systems

internally maintain their own queue of the IRPs that it needs to process. This

queuing can affect the time taken for to complete an IRP.

The fragmentation of the disk also affects the transfer rate of the disk: When

fragmented, the files in the file system are written in small pieces on the hard disk,

thus scattering the available disk space. Disk fragmentation increases access time

and reduces file system efficiency. Performance can suffer if the file becomes

www.cswl.com


severely fragmented. If the file is highly fragmented, there will be a considerable

variation in the seek rate. This variation would reduce the disk bandwidth.

Handling Fast I/O:Fast I/O is performed if the file stream is cached and it is

always a synchronous operation. Fast I/O is a procedure-based interface between

the I/O Manager and the file system drivers. The Fast I/O interface makes it

possible for FSDs to process certain operations, including some read and write

operations, without the use of Irps.

In Fast I/O, request parameters are passed from the I/O Manager to the FSD as

function parameters. Because the FSD is called in the context of the requesting

thread, the parameters that are passed in are all that the FSD requires to process the

request.

Guaranteeing Fast I/o is one of the major challenges in providing guaranteed I/O

for an application. Since the I/O Manager does not create an irp in this case, it is

virtually impossible to guarantee Fast I/O calls.

Handling System Irps:Systems Irps are those that are generated by the system to

perform certain disk activities. System Irps are mostly generated for a paging

operation. Such Irps have if not handled properly by us, might result in

unpredictable performance. Moreover, these system Irps do use some amount of the

disk bandwidth. This is done at the expense of the bandwidth that has been

allocated to some other application. Therefore the application might not be getting

its share of the bandwidth when there is a sudden increase in the number of such

system Irps.

www.cswl.com


Implemented Solution

The ideal mechanism to provide guaranteed I/O would be to design a filter driver

above the file system driver. The Windows NT I/O Manager includes the capability

for one kernel mode driver to “attach” one of its Device Objects to a Device Object

created by a different driver. The result of this is that IRPs destined for the driver

associated with the original Device Object will be sent to the driver associated with

the “attached” Device Object. This attached driver is the Filter Driver. This filter

driver can then examine, modify, complete, or pass along the IRPs it receives to the

original driver.

Therefore a driver attached to the file system driver would intercept all the I/O

requests targeted at the file system driver.

These Irps may then be re-ordered and dispatched to the file system driver so that

the bandwidth requirement of all the reserved applications is satisfied. The Irps

generated by those applications that require more bandwidth are dispatched before

www.cswl.com


the Irps from other applications. This ensures that more requests of a guaranteed

application are processed when compared to a non-guaranteed application.

How filter gets control

Whenever any user's i/o request is received by the i/o manager for a file residing on

a mounted logical volume, the I/O Manager normally forwards the request to the

file system driver managing the mounted logical volume.

Before forwarding the request, however, the I/O Manager also checks to see if any

other device object has layered itself over the device object representing the

mounted logical volume and redirects the request to that device object, which is at

the top of the layered list of device objects. Therefore, the filter driver module

intercepts the I/O before it reaches the file system.

Hence once the filter is attached to the file system that is to be guaranteed, the filter

intercepts all the Irps that the I/O manager sends down to the FSD. The filter may

then manipulate these Irps and then dispatch then to the underlying FSD.

Note that the file system driver has no idea that some other filter driver is layered

above it. It behaves as if the I/O Manager has sent the user request directly to it.

www.cswl.com


The figure above shows the flow of IRP through the system after the Guaranteed

I/O filter driver is attached to the File system driver.

Step 1. The I/O manager creates the IRP for the operation that it needs to do. It fills

the stack location corresponding to the driver that is at the top of the layer (in this

case our filter).

Step 2. The filter on receiving the IRP does some processing that needs to be done.

Step 3. The filter then returns the IRP the I/O manager copying its stack to the

lower drivers stack location.

Step 4. The I/O manager then passed on the IRP to the next driver in the order (this

case it is the FSD).

Step 5. The lower level driver now processes the IRP. The lower level driver uses

its own stack in the IRP for the processing.

www.cswl.com


Step 6. The lower level driver (FSD) returns the IRP back to the I/O manager. The

I/O manager then releases whatever resource was allocated to the IRP.

What the filter does?

The filter driver determines the total bandwidth of the disk. This is accomplished

by generating read requests and estimating the time taken to service these IRPs.

The total bandwidth is split into two pools – Guaranteed Bandwidth Pool and the

Non Guaranteed Bandwidth Pool. As the names suggest, the applications that have

reserved bandwidth eat into the Guaranteed Bandwidth Pool and the unreserved

applications use the Non Guaranteed Bandwidth Pool.

The driver traps the Irps intended for the file system driver. These Irps are then

dispatched based on the bandwidth requirements of the applications. The

bandwidth required by each application is specified through a User Interface. The

bandwidth is specified as the number of bytes to be accessed by the application in

“n” seconds (referred to as a time quantum hereafter).

The filter keeps track of the time quantum of all the applications and refreshes

them. The time quantum of an application begins as soon as the application starts.

www.cswl.com


1. Reservation Manager

2. Collector

3. Scheduler

4. Dispatcher

Reservation Manager:

The Reservation Manager is responsible for maintaining the reservation details

within the system. The Reservation Manager may receive calls from the User

Interface Module to add, delete or modify the bandwidth information for an

application. This information contains the name of the application and the amount

of bandwidth associated with it. The Reservation Manager maintains an internal

data structure known as the Bandwidth Allocation Table to keep track of the

bandwidth reservations. When the Reservation Manager receives a call from the UI

Module to make a new reservation, it generates a new ID for the reservation and

www.cswl.com


makes an entry in the BAT. The reservation manager also stores in the BAT an

entry corresponding to the non-guaranteed bandwidth pool, which will be used by

all the unreserved applications.

The reservation for an application is valid only when it starts. Till then the

unreserved applications are allowed to eat into this bandwidth. The filter receives a

notification whenever a process is created or deleted. This is accomplished by

registering a "Process Notification Routine" with the system. Once such a routine

has been registered, the system will invoke it whenever a process is either created

or deleted. The bandwidth used by a reserved application is released to the non-

guaranteed pool when it exits. Thus the reservation is valid only during the lifetime

of an application. This ensures that there are no "bandwidth leaks" within the

system.

Collector:

The basic function of the collector is to trap all IRPs that are sent by the I/O

Manager to the filter. On receiving an IRP from the IO Manager, the collector

determines the name of the application that issued the request. It then passes this

information to the Reservation Manager, which updates the BAT with the number

of bytes being accessed by the irp. The Collector then time stamps this IRP with the

time before which it has to be dispatched. The time stamped irp is then sent to the

Scheduler where it is queued in a list.

Scheduler:

The Scheduler is a separate thread that dispatches Irps to the Dispatcher. The

Scheduler maintains a data structure Pending IRP List (hereafter referred to as the

PIL) to which the Collector adds the Irps. Based on the time stamp on the irp, the

scheduler removes it from the list and sends it to the Dispatcher. If the time stamp

of the IRP corresponds to the next time-quantum of the application, the Scheduler

www.cswl.com


goes into a wait state after setting a timer. The timer is set to expire at the

beginning of the next time quantum.

The Scheduler does processing only on receiving a notification. The Scheduler is

notified whenever a new irp is added to the PIL or by a timer object, which was set

by the Scheduler.

Dispatcher:

The Dispatcher receives IRPs that are to be dispatched immediately from the

Scheduler and sends them to the underlying File System Driver. The dispatcher is

also responsible for estimating the bandwidth of the disk. The dispatcher

accomplishes this by timing each irp that is serviced.

Scheduling logic of the filter using time stamps

Bandwidth is defined as the number of bytes that are serviced in a time quantum of

‘n’ seconds. The scheduling of the Irps is based on the time stamps affixed on the

Irps. The Irps are time stamped based on the bandwidth used by the application in a

time quantum.

The time quantum of an application begins when the application starts. If the

bandwidth for an application is not satisfied for the current time quantum, the time

taken to service the irp is estimated. If the estimated time is within the current time

quantum of the application, the irp is dispatched immediately to the FSD. If this

estimated exceeds the current time quantum, the irp is time stamped to the next

time quantum. This time stamped irp is added to the PIL.

If the application has already utilized its allocated bandwidth, the irp is time

stamped to the next time quantum and is added to the PIL. The bandwidth utilized

by the application for the current time quantum is reset.

www.cswl.com


A separate thread removes the time stamped Irps from the PIL and dispatches them

to the FSD. The thread begins processing the PIL on receiving a notification. This

may either be due to an addition of a new irp to the PIL or by a timer set by the

thread.

The Irps are dispatched based on their respective time stamp. If the time stamp

indicated that the irp has to be dispatched in the current time quantum, the irp is

removed from the PIL and is dispatched to the FSD. If the time stamp on the irp

does not correspond to the current time quantum of the application; the thread sets

a timer and goes into a “wait state”. The timer is set to expire at the beginning of

the next time quantum of the application.

Installation, testing and debugging

Installation:

Installing device drivers on Windows NT is extremely simple. The entire process

consists of only two steps:

1. Copy the necessary files to the system.These files include the driver

executable image (.sys) file, as well as any other files (such as file

containing configuration information) that are required by the driver.

2. Create the necessary Registry entries:These entries indicate when the

driver is to be started, and also store any driver specific or device specific

information that the driver may need during its initialization process. Each

driver in Windows NT must have its own key in the Registry, named with

the driver’s name, under the

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services key.

Briefly, the value entries relevant to driver startup that may appear under a

driver’s Services key are as follows:

www.cswl.com


• Type:This value indicates the type of component (driver, files

system, or application) that this represents.

• Start:This value tells the system whether it should attempt to start

this driver during system startup and, if so, during what phase of

system startup it should attempt it.

• Group:This value allows the driver writer to specify a specific

startup order for their driver order within a given system startup

phase.

• Tag:This value allows us to establish a specific order in a particular

startup group.

• Error Control:This value indicates what action the system should

take if it attempts to start a driver but fails.

• DependOnGroup/DependOnService:This value identifies a

prerequisite group or a specific driver on which the driver depends.

• Image Path:This value contains the path to the driver image file.

• Display Name:This is the text name of the driver to be displayed.

Testing:

The following test cases can be employed to evaluate the functioning of the

Guaranteed I/O filter driver.

Test I

Many disk intensive applications were run simultaneously on the disk on which the

guarantees are made.

Now the media player is run making bandwidth reservations so that it runs

smoothly.

Test II

www.cswl.com


A CPU intensive program (some program that does a tight loop) is run.


smoothly.

Test III

Both test I and Test II are performed together


smoothly.

Debugging:

Debugging kernel mode drivers is a slow process. There are a few debuggers that

may be used to debug kernel mode drivers. The most prominent among them are

WinDbg and SoftICE.

About WinDbg:

The standard remote debugger that is supplied as part of the Windows NT SDK is

WinDbg. WinDbg is a full-featured multi-window debugger. It supports source-

level debugging in either C or assembler language. Breakpoints of all types (static,

conditional, and the like) may be set using the driver’s source code. Using WinDbg

it is possible to perform single-step program execution (stepping either into or over

called functions), examine local variables and change them.

About SoftICE

SoftICE combines the power of a hardware debugger with the ease of use of a

symbolic debugger. It provides hardware-like breakpoints and sticky breakpoints

that follow the memory as the operating system discards, reloads, and swaps pages.

SoftICE displays your source code as you debug, and lets you access your local and

global data through their symbolic names.

www.cswl.com


SoftICE consists of the SoftICE kernel-mode debugger and the Symbol Loader

utility. The SoftICE debugger (SoftICE) is an advanced, all-purpose debugger that

can debug virtually any type of code including interrupt routines, processor level

changes, and I/O drivers. The Symbol Loader utility loads the debug information

for your module into SoftICE, maintains the SoftICE initialization settings, and lets

you save the contents of the SoftICE history buffer to a file.

Hints and tips regarding driver debugging:

The section contains the most random collection of hints and tips regarding driver

debugging.

Displaying output messages:

One of the simplest ways to debug kernel mode drivers is to display appropriate

output messages at whenever necessary in the driver. This allows us to keep track

of the control flow of the driver and trace the bugs and other shortcomings in the

driver.

Asserting Assumptions:

A well known technique for writing solid code is the use of the ASSERT () macro.

This function allows you to check, at runtime, that your assumptions are true.

Where to go from here?

• Guaranteeing I/O for multiple disks

• Porting to Windows 2000

• Improve the bandwidth estimation

www.cswl.com


References

Web site references:

http://www.eu.microsoft.com/hwdev/ddk/ddk40.htm

http://www.intec.es/ddk

http://www.sysinternals.com/

News Groups and Mailing Lists:

• Comp.os.ms-windows.programmer.nt.kernel-mode

• Microsoft.public.win32.programmer.kernel

• [email protected]

• [email protected]

Books:

• Inside Windows NT – David Solomon

• The Windows NT Device Driver development – Peter G. Viscarola and W.

Anthony Mason

• Windows NT File System Internals – Rajeev Nagar

• The Windows NT Device Driver book – Art Baker

----------------------------------------------------------------------------------------------------------- Copyright Notice: 2002 California Software Labs. All rights Reserved. The contents on the document are not to be reproduced or duplicated in any form or kind, either in part or full, without the written permission of California Software labs. Product and company names mentioned here in are the trademarks of their respective companies.

http://www.eu.microsoft.com/hwdev/ddk/ddk40.htm

http://www.intec.es/ddk

http://www.sysinternals.com/



i/o file system filter driver for windows nt

Documents