Window IO
description
Transcript of Window IO
Provide consistent I/O abstraction to applications.
Provide a framework to do the following.◦ Dynamic loading/unloading of drivers.
◦ Support for power management so that the system or individual devices can enter low power states.
◦ Driver layering.
◦ Asynchronous I/O.
◦ Uniform enforcement of security.
All I/O requests to drivers are sent as I/O request packets (IRPs).
I/O operations are layered
The I/O manager defines a set of standard routines, some required and others optional, that drivers can support
With each user-mode request for I/O, the I/O Manager allocates an IRP from nonpaged system memory. Based on the file handle and I/O function requested by the user, the I/O Manager passes the IRP to the appropriate driver dispatch routine.
The dispatch routine checks the parameters of the request, and if valid, passes the IRP to the driver's Start I/O routine.
The Start I/O routine uses the contents of the IRP to begin a device operation.
When the operation is complete, the driver's DpcForIsrroutine stores a final status code in the IRP and returns it to the I/O Manager.
The I/O Manager uses the information in the IRP to complete the request and send the user the final status
Major function
IRP_MJ_CLOSE,IRP_MJ_CREATE,IRP_MJ_DEVICE_CONTROL,IRP_MJ_INTERNAL_DEVICE_CONTROL,IRP_MJ_PNP,IRP_MJ_POWER,IRP_MJ_READ..
Minor Function
IRP_MN_START_DEVICE,IRP_MN_QUERY_ID,IRP_MN_EJECT....
IO priority
User plugs a new device into a Bus
The Bus driver
◦ Notices the new device’s arrival
◦ Enumerates the device
◦ Retrieves identification information for the device
◦ Passes information to Plug and Play
driver must implement a Plug and Play dispatch routine, a power management dispatch routine
Need to handle both add and removal of device
devnode is made up of at least two, and sometimes more, device objects[PDO and FDO]
A physical device object (PDO) that the PnP manager instructs a bus driver to create when the bus driver reports the presence of a device on its bus during enumeration A functional device object (FDO) that is created by the driver, which is called a function driver, that the PnP manager loads to manage a detected device.
user plugin device ->bus driver enumerates device ->bus driver notifies ->pnp obtains information via IRP_MN_QUERY_DEVICE_RELATIONS=>The function driver for the bus device handles the IRP.
PnP manager creates devnodes ->PnP manager gathers information via IRP
_MN_QUERY_ID ->store them in registry
PnP manager coordinates with the user-mode PnP manager and user-mode Setup PnP manager ->user-mode Setup components direct the kernel-mode PnP manager to load the function and filter drivers.
Require hardware that complies with the Advanced Configuration and Power Interface (ACPI) specification
Power Management split into:
S-states, representing the entire system
S0: Working state, S1 – S3: Sleeping states
S4: Hibernated state, S5: Soft-off state
D-states, representing single devices
D0: Working state, D1 – D2: Low power states, D3: Off state
This can vary based on architecture and device manufacturer and corresponding drivers
Devices can be in any Dx state while the machine itself is in the S0 state
S0-D0: Device is powered on and fully active
S0-D(1-3): Device is in a low power state, but the machine is still running. The user may not even be aware that the device is not in D0
Devices in D(1-3) may be armed for wakeup, even though the machine is awake
Machine appears to be off
RAM context is maintained
All clocks are stopped, except for RTC
Devices may or may not have power
Some devices may have trickle current, but not main power source
Power in S1 >= S2 >= S3
Differences between S1, S2 and S3 are machine specific
RAM context is written to disk
Machine is powered off
All devices are in the D3 state, unless they have external power sources
Machine execution resumes through NTLDR, which restores RAM context
BIOS has a chance to reprogram devices
S5 State: All context is lost
Machine is powered off
Resume from S5 == booting
Hybrid sleepa user request to put the computer to sleep will actually be a combination of both the S3 state and the S4 state: while the computer is put to sleep, an emergency hibernation file will also be written to disk
Connected standby:
<<to be filled>>
The WDM Power Manager sends S IRPs:
IRP_MN_QUERY_POWER, IRP_MN_SET_POWER
Each device stack has a “Power Policy Owner” who converts S IRPs to D IRPs
The Power Policy Owner is typically the FDO
The mapping comes from the S D array stored in the IRP_MN_QUERY_CAPABILITIES structure
Each entry calls out the lightest possible D state for a given S state
Mappings can be rounded down (deeper)
The Power Policy Owner then uses PoRequestPowerIrp to request the appropriate D IRP
Windbg Command:
!thread – to get the test status of thread and corresponding irp detail
!drvobj,!devobj –to det driver and device object detail
!irpfind – displays information about all I/O request packets (IRP) currently allocated in the target system
!irp <addres of irp> - to get etails of particular irp.
Enable Verifier option for IRP Logging to trace irp
All Question are welcomed
Thank You