The I/O Manager is the part of the Windows NT Executive that manages all input and output for the operating system. A large part of the I/O Manager's role is to manage communications between drivers. The I/O Manager supports all file system drivers, hardware device drivers, and network drivers and provides a heterogeneous environment for them. It provides a formal interface that all drivers can call. This uniform interface allows the I/O Manager to communicate with all drivers in the same way, without any knowledge of how the devices they control actually work. The I/O Manager also includes driver support routines specifically designed for file system drivers, for hardware device drivers, and for network drivers.
The Windows NT I/O model uses a layered architecture that allows separate drivers to implement each logically distinct layer of I/O processing. For example, drivers in the lowest layer manipulate the computer's physical devices (called device drivers). Other drivers are then layered on top of the device drivers, as shown in Figure 1.6. These higher-level drivers do not know any details about the physical devices. With the help of the I/O Manager, higher-level drivers simply pass logical I/O requests down to the device drivers, which access the physical devices on their behalf. The Windows NT installable file systems and network redirectors are examples of high-level drivers that work in this way.
Figure 1.6 Layered Device Drivers
This scheme allows easy replacement of file system drivers and device drivers. It allows multiple file systems and devices to be active at the same time while being addressed through a formal interface.
Drivers communicate with each other using data structures called I/O request packets. The drivers pass I/O request packets to each other via the I/O Manager, which delivers the packets to the appropriate target drivers using the drivers' standard services. The simplest way to perform an I/O operation is to synchronize the execution of applications with completion of the I/O operations that they request. (This is known as synchronous I/O.) When such an application performs an I/O operation, the application's processing is blocked. When the I/O operation is complete, the application is allowed to continue processing.
One way that applications can optimize their performance is to perform asynchronous I/O, a method employed by many of the processes in Windows NT. When an application initiates an I/O operation, the I/O Manager accepts the request but doesn't block the application's execution while the I/O operation is being performed. Instead, the application is allowed to continue doing work. Most I/O devices are very slow in comparison to a computer's processor, so an application can do a lot of work while waiting to be notified that an I/O operation is complete.
When an environment subsystem issues an asynchronous I/O request, the I/O Manager returns to the environment subsystem immediately after putting the request in a queue, without waiting for the device driver to complete its operations. Meanwhile, a separate thread from the I/O Manager runs requests from the queue in the most efficient order (not necessarily the order received).
When each I/O request is finished, the I/O Manager notifies the process that requested the I/O.
Figure 1.7 Queued I/O Requests
While asynchronous I/O permits an application to use the computer's processor during I/O operations, it also makes it harder for the application to determine when I/O operations have been completed. Some applications provide a callback function (APC) that is called when the asynchronous I/O operation is completed. Other applications use synchronization objects, such as an event or the file handle, that the I/O system sets to the signaled state when the I/O operation is complete.
The I/O architecture includes a single Cache Manager that handles caching for the entire I/O system. Caching is a method used by a file system to improve performance. For example, instead of reading and writing directly to the disk, frequently used files are temporarily stored in a cache in memory, and reads and writes to those files are performed in memory. Reading and writing to memory is much faster than reading and writing to disk.
The Cache Manager uses a file-mapping model that is closely integrated with the Windows NT Virtual Memory Management. Cache Manager provides caching services to all file systems and network components under the control of the I/O Manager. Cache Manager can dynamically grow and shrink the size of the cache as the amount of available RAM varies. When a process opens a file that already resides in the cache, Cache Manager simply copies data from the cache to the process's virtual address space, and vice versa, as reads and writes are performed.
Cache Manager offers services such as lazy write and lazy commit, which can improve overall file system performance. Lazy write is the ability to record changes in the file structure cache, which is quicker than recording them on disk, and then later, when demand on the computer's central processing unit (CPU) is low, the Cache Manager writes the changes to the disk. Lazy commit is similar to lazy write. Instead of immediately marking a transaction as successfully completed, the committed information is cached and later written to the file system log as a background process.
For more information about how file systems interact with Cache Manager, see Chapter 5, "Windows NT File Systems and Advanced Disk Management."
In the Windows NT I/O architecture, file system drivers are managed by the I/O Manager. Windows NT supports multiple active file systems, including existing file systems such as FAT. Windows NT supports FAT and HPFS file systems for backward compatibility with MS-DOS, Windows 3.x, and OS/2 1.x operating systems.
Windows NT also supports NTFS — a new file system designed for use with Windows NT. NTFS provides many features including file system security, Unicode support, recoverability, long filename support, and support for POSIX.
The Windows NT I/O architecture not only supports traditional file systems but has implemented its network redirector and server as file system drivers. From the perspective of I/O Manager, there is no difference between accessing files stored on a remote networked computer and accessing those stored locally on a hard disk. In addition, redirectors and servers can be loaded and unloaded dynamically, just like any other driver, and multiple redirectors and servers can coexist on the same computer.
For more information about supported file systems, see Chapter 5 "Windows NT File Systems and Advanced Disk Management." For more information about supported redirectors and servers, see Chapter 1, "Windows NT Networking Architecture," in the Networking Guide.
Hardware device drivers are also components of the I/O architecture. All hardware device drivers (such as printer drivers, mouse drivers, and disk drivers) are written in the C programming language, are 32-bit addressable, and are multiprocessor-safe.
Device drivers access the hardware registers of the peripheral devices through support routines that are supplied by the Windows NT operating system. There is a set of these routines for every platform that Windows NT supports; since the routine names are the same for all platforms, device drivers for Windows NT are portable across different processor types.
Designers of device drivers are encouraged to create separate drivers for different devices, rather than monolithic drivers, and the design of I/O Manager makes it easy to do so. This allows more flexibility to customize device configurations on the computer and to layer device drivers and other drivers.
For example, the Intel 8042 processor is an interface device— the keyboard and mouse communicate with the i8042 driver as well as with their own respective drivers. Three separate drivers are used — for the i8042, for the keyboard, and for the mouse — rather than one large monolithic driver. This makes it easier to change one component (exchanging the mouse for a different pointing device, for example).
A third type of driver implemented as a component in the I/O architecture is network device drivers. Windows NT includes integrated networking capabilities and support for distributed applications. As shown in Figure 1.8, networking is supported by a series of network drivers.
Figure 1.8 Networking Components in Windows NT
Redirectors and servers are implemented as file system drivers and run at or below a provider interface layer where NetBIOS and Windows Sockets reside.
Transport protocol drivers communicate with redirectors and servers through a layer called the Transport Driver Interface (TDI). Windows NT includes a number of transports:
At the bottom of the networking architecture is the network adapter card device driver. Windows NT currently supports device drivers written to the Network Device Interface Specification (NDIS) version 3.0. NDIS allows for a flexible environment of data exchange between transport protocols and network adapters. NDIS 3.0 allows a single computer to have several network adapter cards installed in it. In turn, each network adapter card can support multiple transport protocols for access to multiple types of network servers.
For more information about network device drivers, see Chapter 1, "Windows NT Networking Architecture," in the Networking Guide.