• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            隨筆-60  評論-98  文章-0  trackbacks-0

            根據(jù)MSDN翻譯的,網(wǎng)上許多兄弟問此類的問題,解答很少。希望本文能有所幫助。

            IRP_MJ_CLEANUP

            保持進(jìn)程定義上下文信息的驅(qū)動器,必須在DispatchCleanup中包含cleanup請求。

            何時發(fā)送:
            收到IRP_MJ_CLEANUP意味著請求的目標(biāo)設(shè)備與目標(biāo)文件的句柄相關(guān)(也可能因為io請求后沒有釋放)

            入?yún)ⅲ?br>無

            出參:

            操作:
            該IRP在關(guān)閉 file  object 句柄的進(jìn)程上下文中發(fā)送。因此,驅(qū)動器應(yīng)該釋放進(jìn)程上下文中所指定的資源,比如之前驅(qū)動器鎖定或映射的user memory等。
            如果驅(qū)動器的 device objects 狀態(tài)是exclusive,則該device是獨占性的,一次只能為一個線程服務(wù)。驅(qū)動器必須結(jié)束當(dāng)前目標(biāo) device object 隊列中的所有IRP,并設(shè)置其I/O status block為STATUS_CANCELLED。
            另外,驅(qū)動器只是需要取消并結(jié)束與待釋放的file object句柄相關(guān)的IRP隊列成員。(指向file object的指針位于驅(qū)動器IRP IO_STACK_LOCATION的FileObject成員中。)取消隊列中的IRP后,驅(qū)動器結(jié)束了clear up IRP操作,并將自身的I/O status block置為STATUS_SUCCESS。
            //------------------------------------------------------------------------------------------
            IRP_MJ_CLOSE

            驅(qū)動器必須在DispatchClose中包含關(guān)閉請求和驅(qū)動器的可能發(fā)生的異常,因為該驅(qū)動器只能通過關(guān)閉系統(tǒng)來卸載設(shè)備,保持了系統(tǒng)分頁文件的的磁盤驅(qū)動器就屬于這類驅(qū)動器。具有該類特性驅(qū)動器支持動態(tài)卸載。

            何時發(fā)送:
            收到IRP_MJ_CLOSE請求意味著與目標(biāo)device object相關(guān)的file object句柄已經(jīng)關(guān)閉或釋放。所有的外部I/O請求都已結(jié)束或取消。

            入?yún)ⅲ?br>無

            出參:

            操作:
            很少有設(shè)備會設(shè)置IRP的status block為STATUS_SUCCESS結(jié)束關(guān)閉請求。驅(qū)動器如何處理關(guān)閉請求取決于其設(shè)計。通常,驅(qū)動器在收到IRP_MJ_CREATE后會undo自己的操作結(jié)果。device object為exclusive的驅(qū)動器,比如串行驅(qū)動器,在收到該請求后也可能會reset硬件。
            IRP_MJ_CLOSE不是在關(guān)閉了file object句柄的進(jìn)程上下文中發(fā)送的。如果驅(qū)動器必須釋放進(jìn)程指定的資源,比如驅(qū)動器之前鎖定或映射的user memeory等,就會對IRP_MJ_CLEANUP請求做同樣的響應(yīng)。
            //------------------------------------------------------------------------------------------
            IRP_MJ_CREATE

            kernel-mode驅(qū)動器必須在DispatchCreate或DispatchCreateClose中提出創(chuàng)建請求。

            何時發(fā)送:
            收到該請求意味著user-mode保護(hù)的子系統(tǒng)(可能代表的是某個應(yīng)用程序),請求一個file object句柄,該局并代表特定的目標(biāo)device object,或者是較高級別的驅(qū)動器正在連接器device object到目標(biāo)device object。

            入?yún)ⅲ?br>無

            出參:

            操作:
            與IRP_MJ_CLOSE類似,對IRP_MJ_CREATE的相應(yīng)取決與驅(qū)動器的設(shè)計,很少有驅(qū)動器會設(shè)置IRP的I/O status block為STATUS_SUCCESS。帶有pageable-image單元的驅(qū)動器,像系統(tǒng)串行驅(qū)動器,會通過映射自身的page-out代碼,來為那些嘗試打開設(shè)備進(jìn)行I/O操作的user-mode線程提供資源。

            //------------------------------------------------------------------------------------------
            IRP_MJ_DIRECTORY_CONTROL

            何時發(fā)送:
            IRP_MJ_DIRECTORY_CONTROL請求是由I/O管理器和其他操作系統(tǒng)組件(比如kernel-mode驅(qū)動器)發(fā)送的。當(dāng)user-mode程序調(diào)用ReadDirectoryChangesW、FindNextVolumeMountPoint或者kernal-mode componenet調(diào)用ZwQueryDirectoryFile時,會發(fā)送該請求。

            操作:文件系統(tǒng)驅(qū)動器
            文件系統(tǒng)驅(qū)動器通過檢查監(jiān)控程序code來判斷判斷執(zhí)行哪一個目錄控制操作。有效的監(jiān)控程序codes:
            IRP_MN_NOTIFY_CHANGE_DIRECTORY
            請求告知目錄變更。通常文件系統(tǒng)驅(qū)動器會將此IRP放到私有的隊列中,而不是立即進(jìn)行滿足該請求。 當(dāng)目錄發(fā)生變更時,文件系統(tǒng)驅(qū)動器執(zhí)行通知目錄變更操作,出隊,結(jié)束該IRP。
            IRP_MN_QUERY_DIRECTORY
            目錄查詢請求。消息類型因文件系統(tǒng)而異,通常包括以下幾種:
            FileBothDirectoryInformation
            FileDirectoryInformation
            FileFullDirectoryInformation
            FileIdBothDirectoryInformation
            FileIdFullDirectoryInformation
            FileNamesInformation
            FileObjectIdInformation
            FileReparsePointInformation

            注意:FileQuotaInformation類已不再使用,用IRP_MJ_QUERY_QUOTA代替。
            執(zhí)行之后,結(jié)束IRP。

            操作:文件系統(tǒng)過濾驅(qū)動器
            過濾驅(qū)動器將該IRP向棧上的下一層驅(qū)動器傳遞。
            //------------------------------------------------------------------------------------------
            IRP_MJ_QUERY_INFORMATION

            何時發(fā)送:
            IRP_MJ_QUERY_INFORMATION請求的發(fā)送和IRP_MJ_DIRECTORY_CONTROL類似,是由I/O管理器和其他操作系統(tǒng)組件(比如kernel-mode驅(qū)動器)發(fā)送的。調(diào)用GetFileInformationByHandle或ZwQueryInformationFile時發(fā)送。

            操作:文件系統(tǒng)驅(qū)動器
            文件系統(tǒng)驅(qū)動器提取file object信息并進(jìn)行解析,由此判斷用戶是打開一個文件還是打開一個目錄,這樣,驅(qū)動器處理查詢并結(jié)束IRP。如果不能對信息進(jìn)行提取解析,驅(qū)動器結(jié)束IRP,不處理查詢。
            可供查詢的文件和目錄信息因文件系統(tǒng)而異,通常包括如下幾種:
            FileAllInformation
            FileAttributeTagInformation
            FileBasicInformation
            FileCompressionInformation
            FileEaInformation
            FileInternalInformation
            FileNameInformation
            FileNetworkOpenInformation
            FilePositionInformation
            FileStandardInformation
            FileStreamInformation
            ZwQueryInformationFile支持FileAccessInformation, FileAlignmentInformation, 和 FileModeInformation 類型,而無需向文件系統(tǒng)發(fā)送IRP_MJ_QUERY_INFORMATION請求,因為他們與文件系統(tǒng)無關(guān)。

            操作:文件系統(tǒng)過濾驅(qū)動器
            過濾驅(qū)動器將該IRP向棧上的下一層驅(qū)動器傳遞。
            //------------------------------------------------------------------------------------------
            IRP_MJ_QUERY_VOLUME_INFORMATION

            何時發(fā)送:
            IRP_MJ_QUERY_VOLUME_INFORMATION請求由I/O管理器發(fā)送。當(dāng)user-mode程序調(diào)用GetDiskFreeSpace或GetFileType時會發(fā)送該請求。

            操作:文件系統(tǒng)驅(qū)動器
            文件系統(tǒng)驅(qū)動器通過對file object進(jìn)行提取和解碼,判斷目標(biāo)device object是不是該文件系統(tǒng)的control device object。如果是,并且請求的是打開volume(或者打開volume上的object),文件系統(tǒng)驅(qū)動器會處理請求并結(jié)束IRP。如果不是,文件系統(tǒng)驅(qū)動器查詢失敗,結(jié)束IRP。
            可供查詢的volume信息類型因文件系統(tǒng)而異,通常有如下幾種類型:
            FileFsAttributeInformation
            FileFsDeviceInformation
            FileFsSizeInformation
            FileFsVolumeInformation

            操作:文件系統(tǒng)過濾驅(qū)動器
            過濾驅(qū)動器將該IRP向棧上的下一層驅(qū)動器傳遞。
            //------------------------------------------------------------------------------------------
            IRP_MJ_READ

            向系統(tǒng)傳遞數(shù)據(jù)的驅(qū)動器必須在DispatchRead或DispatchReadWrite中包含read請求,在此類驅(qū)動器上分層的higher-level驅(qū)動器也必須這樣做。

            何時發(fā)送:
            在完成create請求的之后的時間域內(nèi)發(fā)送。
            可能由包含file object句柄(代表請求過從從該device傳遞數(shù)據(jù)的目標(biāo)device object)的user-mode程序或win32組件發(fā)送。也可能由創(chuàng)建和設(shè)置read IRP的higher-level驅(qū)動器發(fā)送。

            入?yún)ⅲ?br>IRP中的驅(qū)動器I/O stack位置指示Parameters.Read.Length.傳送多少byte數(shù)據(jù)。
            有些驅(qū)動器通過Parameters.Read.Key對在device queue或驅(qū)動器管理的IRP內(nèi)部隊列中對read請求進(jìn)行排序。有的驅(qū)動器通過Parameters.Read.ByteOffset(指示傳送操作的offset)進(jìn)行排序。

            出參:
            根據(jù)驅(qū)動器對device object Flag的是DO_BUFFERED_IO還是DO_DIRECT_IO,采用不同的方法傳遞數(shù)據(jù):
            The buffer at Irp->AssociatedIrp.SystemBuffer if the driver uses buffered I/O
            The buffer described by the MDL at Irp->MdlAddress if the underlying device driver uses direct I/O (DMA or PIO)

            操作:
            接收到read請求之后,higher-level驅(qū)動器會通過為next-lower驅(qū)動器設(shè)置IRP中的I/O stack位置,或者為lower驅(qū)動器創(chuàng)建并設(shè)置附加的IRP。可以調(diào)用IoSetCompletionRoutine設(shè)置IoCompletion(在IRP輸入中是可選的,但在driver-created IRP是必須的)。
            接收到該請求之后,驅(qū)動器將器device傳送給系統(tǒng)memory。結(jié)束IRP的過程中,驅(qū)動器將設(shè)置I/O stack block為傳遞的byte數(shù)量。
             
            //------------------------------------------------------------------------------------------
            IRP_MJ_SET_INFORMATION

            何時發(fā)送:
            IRP_MJ_SET_INFORMATION請求的發(fā)送和IRP_MJ_QUERY_INFORMATION、IRP_MJ_DIRECTORY_CONTROL類似,是由I/O管理器和其他操作系統(tǒng)組件(比如kernel-mode驅(qū)動器)發(fā)送的。調(diào)用SetEndOfFile或ZwSetInformationFile時發(fā)送。

            操作:文件系統(tǒng)驅(qū)動器
            文件系統(tǒng)驅(qū)動器提取file object信息并進(jìn)行解析,由此判斷用戶是打開一個文件還是打開一個目錄,這樣,驅(qū)動器處理查詢并結(jié)束IRP。
            可供設(shè)置的文件、目錄屬性信息如下:
            FileBasicInformation
            FileDispositionInformation
            FileLinkInformation (for file systems that allow cycles to be created in the directory hierarchy)
            FilePositionInformation
            FileRenameInformation
            文件專有屬性:
            FileAllocationInformation
            FileEndOfFileInformation
            FileLinkInformation (for file systems, such as NTFS, that do not allow cycles to be created in the directory hierarchy)
            FileValidDataLengthInformation

            操作:文件系統(tǒng)過濾驅(qū)動器
            過濾驅(qū)動器將該IRP向棧上的下一層驅(qū)動器傳遞。
            //------------------------------------------------------------------------------------------
            IRP_MJ_SET_INFORMATION*
            IRP_MJ_SET_INFORMATION (Serial)

            何時發(fā)送:
            client通過set information請求改變串行設(shè)備上打開的文件結(jié)尾位置時發(fā)送。

            //------------------------------------------------------------------------------------------
            IRP_MJ_WRITE

            向系統(tǒng)傳遞數(shù)據(jù)的驅(qū)動器必須在DispatchWrite或DispatchReadWrite中包含write請求,在此類驅(qū)動器上分層的higher-level驅(qū)動器也必須這樣做。

            何時發(fā)送:
            成功結(jié)束creat請求的時間域內(nèi)。
            可能由包含file object句柄(代表請求過從從該device傳遞數(shù)據(jù)的目標(biāo)device object)的user-mode程序或win32組件發(fā)送。也可能由創(chuàng)建和設(shè)置write IRP的higher-level驅(qū)動器發(fā)送。

            入?yún)ⅲ?br>IRP中的驅(qū)動器I/O stack位置指示Parameters.Write.Length.傳送多少byte數(shù)據(jù)。
            有些驅(qū)動器通過Parameters.Write.Key對在device queue或驅(qū)動器管理的IRP內(nèi)部隊列中對write請求進(jìn)行排序。有的驅(qū)動器通過Parameters.write.ByteOffset(指示傳送操作的offset)進(jìn)行排序。
            根據(jù)驅(qū)動器對device object Flag的是DO_BUFFERED_IO還是DO_DIRECT_IO,采用不同的方法傳遞數(shù)據(jù):
            The buffer at Irp->AssociatedIrp.SystemBuffer, if the driver uses buffered I/O
            The buffer described by the MDL at Irp->MdlAddress, if the underlying device driver uses direct I/O (DMA or PIO)

            出參:

            操作:
            接收到write請求之后,higher-level驅(qū)動器會通過為next-lower驅(qū)動器設(shè)置IRP中的I/O stack位置,或者為lower驅(qū)動器創(chuàng)建并設(shè)置附加的IRP。可以調(diào)用IoSetCompletionRoutine設(shè)置IoCompletion(在IRP輸入中是可選的,但在driver-created IRP是必須的)。之后,驅(qū)動器通過IoCallDriver傳遞請求給next-lower驅(qū)動器。
            接收到該請求之后,驅(qū)動器將數(shù)據(jù)從系統(tǒng)memory傳遞到自身的device。結(jié)束IRP的過程中,驅(qū)動器將設(shè)置I/O stack block為傳遞的byte數(shù)量。
            //------------------------------------------------------------------------------------------
            IRP_MJ_WRITE*
            分段寫入,提供Offset,每次寫入65536字節(jié)。

            posted on 2007-12-22 16:36 創(chuàng)建更好的解決方案 閱讀(6049) 評論(0)  編輯 收藏 引用 所屬分類: 性能監(jiān)測

            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            久久影院综合精品| 99精品国产综合久久久久五月天| 久久久久国产亚洲AV麻豆| 亚洲欧美一区二区三区久久| 久久人人爽人人爽人人片AV东京热| 久久久久久极精品久久久| 亚洲国产成人精品女人久久久 | 三上悠亚久久精品| 一本色综合网久久| 久久99精品国产自在现线小黄鸭| 国产成人久久777777| 久久电影网| 久久99国产精品尤物| 韩国三级中文字幕hd久久精品| 2021国内久久精品| 久久精品一区二区| 一本色道久久88精品综合| 国产福利电影一区二区三区,免费久久久久久久精 | 国产午夜精品理论片久久影视| 久久久青草久久久青草| 亚洲AV伊人久久青青草原| 精品久久一区二区三区| 久久人人爽人人爽AV片| 91精品国产高清久久久久久国产嫩草| 久久精品桃花综合| 久久综合丁香激情久久| 久久精品无码一区二区WWW| 久久久久国产一区二区| 99久久亚洲综合精品成人| 久久精品人人做人人爽97| 中文字幕热久久久久久久| 综合久久给合久久狠狠狠97色| 亚洲午夜无码AV毛片久久| 91秦先生久久久久久久| 青青青青久久精品国产| 久久国产精品一区二区| 久久精品黄AA片一区二区三区| 日产精品99久久久久久| 亚洲精品午夜国产VA久久成人| 久久福利资源国产精品999| 国产激情久久久久影院老熟女|