Brief Introduction: understanding of file systems, hierarchical drivers, and file read/write

Write by http://hi.baidu.com/weolar/blog/item...2dbb4bd4f.html


Today, I saw sudami learn these things. I haven't learned these things for a long time, so I learned a little bit again. (I just learned some things and I hope you can make a lot of mistakes.
):

In my understanding, a device object (drevobj) is equivalent to a sub-object created by a drive object (drvobj) to form a device chain to accept and process data. The device object is mounted to the device chain,
When the IRP sent by the Device Manager is received (I remember a book saying that there is no really so-called Device Manager, it is just a set of dispatch routines. For example, IopfCallDriver sends the IRP
Dispatched. Hook this function to get a lot of things we want.) in this case, the parent object of the device object-the IRP dispatch function of the driver object
DriverObject-> MajorFunction [IRP_MJ_CREATE] = DispatchCreate;
Will accept and process the IRP. The device stack assists the IRP in finding the dispatch function and storing reusable parameters each time the IRP is delivered.
After talking so much nonsense, what is the problem of accessing and deleting files? For example, if we delete a file, the system process is:

(Application Layer)DeleteFileA
-->
DeleteFileW
-->
Ntdll.ZwSetInformationFil
->
(Driver layer)NtSetInformationFile
->
SrSetInformationFile
->
NtfsNtSetInformationFile
->
NtfsCommonSetInformationFile
->
NtfsSetDispositionInfo
->
MmFlushImageSection
->
MiCleanSection

To the driver layer, windows passes through IRP. The above process
Medium, nt! NtSetInformationFile-> SrSetInformationFile-> NtfsNtSetInformationFile-> NtfsCommonSetInformationFile
At this time, although there are also IRP transfer, but they are still directly called, not in the form of IopfCallDriver. IRP serves to transmit parameters. It keeps the device pair
Image. Now let's take a look at the transmission of an IRP (not a File deleted) in the device chain:

Nt!NtFlushBuffersFile
->

Nt!IopSynchronousServiceTail
->

Sr!SrPassThrough
->

Ntfs!NtfsFsdFlushBuffers
->

Ntfs!LfsFlushToLsn
->

Ntfs!LfsFlushToLsnPriv
->

Ntfs!LfsFlushLbcb
->

Ntfs!LfsFlushLfcb
->

Sr!SrWrite
->

Ntfs!NtfsCommonWrite
->

Ntfs!NtfsNonCachedIo
->

Ntfs!NtfsSingleAsync
->

VolSnap!VolSnapWrite
->

Ftdisk!FtDiskReadWrite
->

CLASSPNP!ClassReadWrite
->

CLASSPNP!ServiceTransferRequest
->

CLASSPNP!SubmitTransferPacket
->

Atapi!IdePortDispatch
(/Driver/atapi/IdeDeviceP0T0L0-3)->

Atapi!IdePortInsertByKeyDeviceQueue
->

Atapi!StartIo Packet
->

HAL->

I/O port ......
That is to say, the IRP is from Ntfs-> ftdisk (volume device)-> class (classpnp)-> atapi-> hal-> IO
.

So //./Physical Drive % d,/Device/Harddisk % d/Partition0 ~ What does it mean? You can learn through DeviceTree and winobj,
/// PhysicalDrive is only a symbolic connection of Device/Harddisk % d/Partition0,

Device/Harddisk0/Partition0 is the symbolic link of/Device/Harddisk0/DR0.

Device/Harddisk0/Partition1, 2 ...... It is the symbolic connection of Device/HarddiskVolume1 and 2.

So what is the device stack? From top to bottom:

Fs driver --->

Volsnap --->

Ftdisk (Device/HarddiskVolume1) --->

Partmgr (Ipartmgr) --->

Disk (Device/Harddisk % d/Partition0/DR0) --->

Acpi --- >>>

Atapi (IdeDeviceP0T0L0-3)

Each layer is attached to the upper layer, so the device chain is formed. The device object created by the driver object is enclosed in brackets to form the device stack and accept the IRP.
(So data can be intercepted when the filter driver is mounted to any layer, which is also the "HOOK" method promoted by Microsoft)

This corresponds to Microsoft's statement, where IRP is a file system-> volume drive-> disk drive-> class drive-> Port Drive-> micro-Port Drive process.

Device/Harddisk % d/Partition0/DR0 is the disk drive object created to process IRP such as ClassReadWrite
. I have read that the IRP_MJ_READ of disk is indeed CLASSPNP! ClassReadWrite, which can accept why the IRP reaches the disk layer instead
To process IRP in classpnp.

In addition, MJ's predecessors also said:
1. The device Station of the file system and the storage device station use the same irp. At atapi, this MINIPORT is replaced by another Irp in pkt,
2. If no one in the middle forwards IRP (such as DISKF), the same IRP is used from FSD to ATAPI. IdePortDispatch has no source code, while
Classpnp is open-source (available in wdk). For more information, see ServiceTransferRequest and
SetupReadWriteTransferPacket.

Where will the IRP go next? Originally, the IRP is put into the queue through IdePortInsertByKeyDeviceQueue in the atapi, and the next step is the ATAPI
StartIo. StartIo no longer has the concept of IRP, so it reaches the HAL (Hardware Abstraction) layer, and then goes down to Port IO!

The following figure shows the figure of Rice students, which is very good. Reference ^ _ ^ first:
IRP |
|
| Attach dev
|
Ntfs/fat32.sys --> dev -->... --> dev
|
| Attach dev
|
|...
|
|
|
|...
|
Partmgr. sys --> dev -->... --> dev
|
|...
|
|
| Dev (/driver/partmgr)
|
Disk. sys --> dev -->... --> dev (DR0)
|

|
| Dev (/driver/partmgr)
|
| Dev (DR0) (/driver/disk)
|
Atapi. sys-> dev -->... --> dev
|
|
...
In addition, AZY's predecessors also said:

Read/write IRP> IdePortDispatch> IoStartPacket> IdePortStartIo.
With DMA capabilities: BmSetup-> BmReceiveScatterGatherList-> ideportallocateaccesen en-> xxx
Without DMA capability: IdePortAllocateAccessToken-> CallIdeStartIoSynchronized-> IdeStartIoSynchronized-> AtapiStartIo-> IO port xxx