Interrupt dispatch block
An internal structure used by the NT Kernel.
Interrupt dispatch table
A Kernel-defined call table with a platform-dependent number of first-level entries (some for DIRQL ISRs) and second-level entries for interrupt transfer routines (dependent on a first-level ISR). For symmetric multiprocessor platforms, the Kernel sets up an IDT for each processor. See also multiprocessor machine.
The NT Kernel reserves eight first-level entries per IDT for its own use; the remaining first-level entries can be connected to a platform-specific I/O bus interrupt by the HAL or to a device interrupt. The Kernel’s reserved entries (in low-to-high IRQL priority) are defined by the following constants:
· PASSIVE_LEVEL - execute thread
· APC_LEVEL - execute special Kernel APC; page fault
· DISPATCH_LEVEL - dispatch (execute DPC)
· WAKE_LEVEL - debugger execution
· CLOCK2_LEVEL - interval-timer execution
· REQUEST_LEVEL - interprocessor request
· POWER_LEVEL - power failure notification
· HIGH_LEVEL - machine checks or bus errors
The set of software and hardware interrupt vectors mapped to these constants is platform-dependent, but none can be connected to a driver’s interrupt object. Note that the constants PASSIVE_LEVEL through DISPATCH_LEVEL and WAKE_LEVEL correspond to software interrupt vectors. DIRQLs for device drivers usually have hardware priority higher than DISPATCH_LEVEL but lower than CLOCK2_LEVEL.
Installable file system
See FS.
A protected subsystem (server) that performs an essential operating system task. For NT, this group includes the Local Security Authority, the Security Accounts Manager, the Session Manager, and the network server. See also protected subsystem.
An intermediate driver processes I/O requests “between” the highest-level driver (frequently a file system driver) and the lowest-level driver that controls the hardware device for which the request is bound. See also class driver, filter driver, and layered driver.
Examples of intermediate drivers include the NT ftdisk driver, which supports fault tolerance, other filter drivers, and many class drivers, particularly those layered over mass-storage device drivers.
An asynchronous hardware signal, usually indicating that a peripheral device needs service, that is detected by the processor. An interrupt causes the processor to save state, to branch to a fixed location, and to resume execution at that location. See also IDT.
A kernel-mode-only, Kernel-defined control object type, used to connect a hardware interrupt source (see DIRQL) and an ISR to an IDT entry, or to connect an ISR and an interrupt transfer routine (dependent on the ISR at its IRQL) to a second-level IDT entry.
Each interrupt object:
· Can be associated with a single IDT entry (and, therefore, with a single processor in an SMP machine)
· Is either LevelSensitive or Latched, depending on the platform, I/O bus, or device
· Can be one of several interrupt objects associated with a given IDT entry if and only if every interrupt object for that entry is of a single type (LevelSensitive or Latched)
For a second-level IDT entry, an ISR, such as an ISR for a bus adapter that is associated with a first-level IRQL routes the interrupt to the device-specific interrupt transfer routine for service via its entry in the IDT.
When more than one set of interrupt objects are connected to the same first-level IDT entry, the corresponding ISRs are called in the same order in which they were connected.
A page-sized range of virtual addresses for which a page fault occurs when any address in the range is referenced. For NT drivers, referencing an invalid page causes a fatal page fault unless the driver is running at an IRQL <= APC_LEVEL when the reference occurs.
a.k.a. “IRP stack location or stack location”
An I/O stack location refers to the part(s) of an IRP that are allocated for each driver in a chain of layered drivers. Each driver owns one of the stack locations in the packet and obtains driver-specific information about what I/O operation to carry out on the target device, using the supplied parameters.
Higher-level drivers in such a chain are responsible for setting up the next-lower driver’s I/O stack location. Any higher-level driver’s I/O stack location can also be used to store context about an operation so that the driver’s IoCompletion routine can perform its cleanup operations. See also IRP.
An I/O status block is a data structure that is part of each IRP. An I/O status block serves two purposes:
· For asynchronous system calls, it provides the user or a higher-level driver’s IoCompletion routine a way of determining whether or not the service worked when the IRP is completed.
· It also provides more information about why the service either worked or did not work.
Upon completion of a system service, the Status field indicates whether the driver(s) that processed the IRP actually satisfied the request or failed the IRP with an error status. The Information field supplies the caller with more information about what actually occurred. For example, it contains the number of bytes actually transferred after a read or write operation.
Interprocess communication
The Windows NT system has two defined, message-passing mechanisms for IPC:
LPC, defining the port object type with a server process that supplies system (port) services to local (using the same physical memory on a single system) client processes
RPC, with an NT-supplied runtime library that implements such RPC capabilities as binding a client process in one address space with a server process in another address space and sending necessary messages to make a remote procedure call possible
I/O request packet
An IRP is the basic I/O Manager structure used to communicate with drivers and to allow drivers to communicate with each other. A packet consists of two different parts:
Header, or fixed part of the packet - This is used by the I/O Manager to store information about the original request, such as the caller’s device-independent parameters, the address of the device object upon which a file is open, etc. It is also used by drivers for storing such information as the final status of the request. See also I/O status block and device object.
I/O stack locations - Following the header is a set of I/O stack locations, one per driver in the chain of layered drivers for which the request is bound. Each stack location contains the parameters, function codes, and context used by the corresponding driver to determine what it is supposed to be doing.
A hardware line over which a peripheral device, bus controller, other processor, or the Kernel signals a request for service to the microprocessor. (IRQ is a common abbreviation for interrupt request line.) See interrupt.
Interrupt request level
The hardware priority level at which a given kernel-mode routine runs, thereby masking off interrupts with equivalent and lower IRQL on the processor. Note that such a routine can be preempted by any interrupt with a higher IRQL. Note also that running at IRQL DISPATCH_LEVEL or higher prevents threads (even those with the highest real-time priority level) from running on the same processor until the current kernel-mode routine lowers IRQL. However, running at raised IRQL on a given processor has no effect on the IRQL of any other processor in a symmetric multiprocessor machine. See also IDT, interrupt object, IRQ, ISR, multiprocessor machine, and priority.
Industry standard architecture
A standard defining the architecture of the PC I/O bus (a.k.a. “AT bus standard”).
Interrupt service routine
A routine whose function is to service a device when it generates an interrupt.
An NT driver’s ISR executes at raised IRQL, usually at the DIRQL of the interrupt object(s) set up for its device (i.e., drivers connected to second-level IDT entries execute at the IRQL of the first-level entry they connect to). Every NT driver’s ISR should execute as quickly as possible, doing only what is necessary to save sufficient state, to make the device stop generating interrupts, and to queue a DPC that completes interrupt processing at a lower IRQL. See also DPC object.