NT Insider: 2017年Linux模块与Windows技术概览
130 浏览量
更新于2024-07-14
收藏 2.69MB PDF 举报
"NT Insider 是一个由 OSR Open Systems Resources, Inc. 发布的计算机科学领域的技术资讯模块，它遵循 GNU General Public License（GPL）的授权。该模块的主要特点是将其内容组织为一个文件系统类型，名为 'The NT Insider'，并在 Linux 内核环境中运行。NT Insider 文件系统（ntinsiderfs）在 2017 年的九月和十月特别活跃，可能包含与 Microsoft Windows 相关的深入技术分析，如 Isolation Minifilter Solution Framework（IMSF）和 Universal Drivers 的讨论。
模块初始化函数 `init_ntinsiderfs_fs` 首先执行 `init_sept_oct_issue()` 函数，这可能是为了处理与九月和十月发布周期相关的任务。如果这个步骤失败，函数会触发一个 panic 来表示文件系统初始化的问题。接下来，模块尝试解决驱动开发者会议相关的问题，如果出现问题，将进入相应的错误处理流程。
模块还涉及到文件系统的注册过程，通过 `register_filesystem(&ntinsiderfs_fs_type)` 方法将 NT Insider 文件系统类型加入到内核中。在这个阶段，如果注册成功，模块会继续执行其他初始化任务；如果注册失败，会调用 `cleanup_cleanup_close_cancel()` 清理已进行的操作。
值得注意的是，模块中提到的 'Isolation Minifilter Solution Framework' 可能是一个隔离过滤器框架，用于提高 Windows 系统的安全性或性能优化。而 'the scoop on universal drivers' 可能是指对通用驱动程序（能够跨硬件平台工作的驱动程序）的详细报道，这在当时的 IT 行业可能是一个热点话题。
NT Insider 是一个专注于提供深度技术见解和Windows系统内部机制的资源，特别是针对驱动开发和安全领域的专业知识，是 IT 专业人员了解 Windows 技术动态的重要渠道。"
Page 6
www.osr.com
The NT Insider Sept - Oct 2017 © OSR Open Systems Resources, Inc.
M
ost of the WDF topics I write about suggest themselves to me as a result of a set of exchanges on our NTDEV list, or as a
result of trends I see in driver code that I review or update. This me, I was inspired by both of these.
There was a recent, and reasonably interesng, thread on NTDEV about the use of Cleanup and Cancel Event Processing Callbacks.
Also recently, I had the opportunity to update two very dierent device drivers. One was a WDM driver that was wrien in the NT
V4 meframe. The other was a KMDF driver wrien by a new Windows driver developer shortly aer the release of KMDF. While
these two drivers were for very dierent types of devices, they had one thing in common: The developers of both misunderstood
how to terminate in-progress Requests and used (or, rather, misused) Cleanup events in place of Cancel.
That’s how I came to be movated to write at length about Cleanup, Close, and Cancel handling in WDF drivers. An addional,
private, movaon is that while we cover this topic in our Wring WDF Drivers seminar, we almost never have the me to talk
about it in the level of depth that I’d prefer. So, I gured an arcle would be useful for many purposes.
Some Preliminaries
The rst thing to understand is that, at least in the driver world (as opposed to the le systems), you need to consider processing
for Cleanup, Close, and Cancel together. This is because they’re oen confused and processing for these funcons oen interact.
Also, as we begin our discussion, please keep in mind that what we say here about Cleanup, Close, and Cancel is enrely specic to
WDF. As in most things WDF, it is never a good idea to aempt to “map” from WDM to WDF (or vice-versa) in your head and
expect to be able to gure things out. That way madness lies. The WDF Framework is its own I/O processing ecosystem. Sure, it
interacts with WDM, but the rules for how WDF drivers work are established solely and enrely by WDF. Just because something
works a certain way in WDM is no reason to believe the same is true for WDF.
The Problem
Let’s start with a couple of simple examples of the problems that Cleanup, Close, and Cancel are designed to solve. I want to
emphasize that these are just two random examples in which these operaons can be useful. There are lots of other important
uses for Cleanup, Close, and Cancel events that these two examples don’t address.
Assume your driver has a single Queue that uses Sequenal Dispatching. A user-mode applicaon successfully calls the Win32
funcon CreateFile specifying FILE_FLAG_OVERLAPPED to allow it to do asynchronous I/O. The app then successfully calls ReadFile
100 mes from within a loop, specifying an OVERLAPPED structure each me. The result is that when the applicaon’s loop is
complete, there are 100 Read Requests pending in your driver.
Now let’s say that applicaon calls CloseHandle on the handle it used to send those 100 reads to your device. At least some of
those 100 reads are sll in progress. What happens to the in-progress I/O Requests? How does your driver handle this situaon?
As a second example, consider what happens when instead of closing the handle to your device when those 100 reads are in
progress, the applicaon exits or is terminated. As Windows begins terminaon processing for the app, your driver potenally has
a pointer to one or more data buers into
which to return data into the applicaon’s
address space. You can see this in Figure 1.
In Figure 1, you can see a driver with a single
WDFQUEUE that has two Read Requests
queued (I didn’t want to put all 100 I/O
Requests in the diagram). Each Read Request
has (stored internally) a pointer to the data
buer into which the Read (output) data is to
be returned.
If Windows were to allow the Process to
terminate completely with I/O requests in
(CONTINUED ON PAGE 7)
Figure 1 -- WDF Driver with 2 Queued Reads;
Each Read Has a Pointer to a User Data Buer
剩余27页未读，继续阅读
2021-04-22 上传
161 浏览量
2021-03-14 上传
2021-05-09 上传
2021-03-31 上传
2021-03-19 上传
175 浏览量
128 浏览量
2023-08-26 上传
weixin_38696590
- 粉丝: 6
- 资源: 927
我的内容管理
展开
