A.2  Designing a SCSI Filter Driver

If a Windows NT SCSI class driver already exists for a particular type of device, it might be unnecessary to write a driver for a new device of the same type. Each system-supplied SCSI class driver was designed to support SCSI-II-compliant peripheral devices of a given type and was tested against a number of vendors’ devices. Thus, any system-supplied SCSI class driver might provide all the support another SCSI-II-compliant device of its type needs.

If an existing SCSI class driver does not fully support a new device of its type, a new driver must be written as either of the following:

·A new SCSI class driver for the device, which, in most cases, is also unnecessary

·Or, an SFD layered over an existing system-supplied class driver

Unless a new device requires that every request be handled in a device-specific manner, writing an SFD takes far less development time than writing a new SCSI class driver.

An SFD supplies device-specific support for requests that require special handling, such as translating data sent to or returned from the device in a nonstandard format, or programming the device in response to an IRP_MJ_DEVICE_CONTROL request. Such an SFD can let the appropriate system SCSI class driver process all I/O requests that require no special handling.