2.1  End-user I/O Requests and NT File Objects

NT drivers are hidden from end users by a Windows NT protected subsystem that implements an already familiar programming interface, such as Windows® or POSIX. Devices are visible to user-mode code, which includes protected subsystems, only as named file objects controlled by the NT I/O Manager.

Figure 2.1 illustrates this relationship between an end user, a subsystem, and the NT I/O Manager.

Figure 2.1    NT File Objects Represent Files, Volumes, and Devices

A Windows NT protected subsystem, such as the Win32® subsystem, passes I/O requests to the appropriate kernel-mode driver through the I/O system services. The subsystem shown in Figure 2.1 depends on support from the NT display, video adapter, keyboard, and mouse device drivers.

A protected subsystem insulates its end users and applications from having to know anything about kernel-mode components, including NT drivers. In turn, the NT I/O Manager insulates protected subsystems from having to know anything about machine-specific device configurations or about NT drivers’ implementations.

The NT I/O Manager’s layered approach also insulates most NT drivers from having to know anything about:

·Whether an I/O request originated in any particular protected subsystem, such as Win32 or POSIX

·Whether a given protected subsystem has particular kinds of user-mode drivers

·What any protected subsystem’s I/O model and interface to drivers is

The I/O Manager supplies NT drivers with a single I/O model, a set of kernel-mode support routines these drivers can use to carry out I/O operations, and a consistent interface between the originator of an I/O request and the NT drivers that must respond to it.

As shown in Figure 2.1, a subsystem and its native applications can access an NT driver’s device or a file on a mass-storage device only through file object handles supplied by the NT I/O Manager. A subsystem’s request to open such a file object and to obtain a handle for I/O to a device or a data file is made by calling the NT I/O system services to open a named file, which can have a subsystem-specific alias (symbolic link) to the kernel-mode name for the file object.

The NT I/O Manager, which exports these system services, is then responsible for locating or creating the file object that represents the device or data file and for locating the appropriate NT driver(s). Figure 2.2 shows an overview of what happens when a subsystem opens a file object representing a data file on behalf of an application.

Figure 2.2    Opening an NT File Object

1.The subsystem calls an NT I/O system service to open a named file.

2.The NT I/O Manager calls the Object Manager to look up the named file and to help it resolve any symbolic links for the file object. It also calls the Security Reference Monitor to check that the subsystem has the correct access rights to open that file object.

3.If the volume is not yet mounted, the I/O Manager suspends the open request, calling one or more NT file systems until one of them recognizes the file object as something it has stored on one of the mass-storage devices the file system uses. When the file system has mounted the volume, the I/O Manager resumes the request.

4.The I/O Manager allocates memory for and initializes an IRP for the open request. To NT drivers, an open is equivalent to a “create” request.

5.The I/O Manager calls the file system driver, passing it the IRP. The file system driver accesses its I/O stack location in the IRP to determine what operation it must carry out, checks parameters, determines if the requested file is in cache, and, if not, sets up the next-lower driver’s I/O stack location in the IRP.

6.Both drivers process the IRP and complete the requested I/O operation, calling kernel-mode support routines supplied by the I/O Manager and by other NT components (not shown in Figure 2.2).

7.The drivers return the IRP to the I/O Manager with the I/O status block set in the IRP to indicate whether the requested operation succeeded or why it failed.

8.The I/O Manager gets the I/O status from the IRP, so it can return status information through the protected subsystem to the original caller.

9.The I/O Manager frees the completed IRP.

10.The I/O Manager returns a handle for the file object to the subsystem if the open operation was successful. If there was an error, it returns appropriate status to the subsystem.

After a subsystem successfully opens a file object that represents a data file, a device, or a volume, the subsystem uses the returned file object handle to request that device I/O operations (usually read, write, or device I/O control requests) be carried out by calling the I/O system services. The I/O Manager routes these requests as IRPs sent to appropriate NT drivers.