文件系统驱动编程基础篇之7.doc

文件系统驱动编程基础篇之7——端口读写 关键字：文件系统驱动编程,端口读写 作者：wskjuf 更新：2008-10-06 22:14:58 浏览：10976 文件系统驱动编程基础篇之七——端口读写 一、前略 本系列文章为业余编程爱好者而写，仅仅作为初学者的一个借鉴，真正的精华存在于参考资料*中。知识的积累将经历从薄到厚，再从厚到薄的反复过程，为了打下牢固的基础，请读者务必在阅读本文的基础上花费必要的时间完成参考资料。笔者的实践环境为：硬件：P35 Motherboard ICH9 chip，Pentium Dual Cpu E2160 1.8g， DDR2 1g软件：Windows XP2、VS 2005、Visual AssistX、DriverStudio 3.2、MICROSOFT.WINDOWS.SERVER.V2003.IFS.DDK、Windbg 6.8.0004.0，请安装好用于调试的虚拟机并配置好调试环境。参考资料*：1．《Programming the Microsoft Windows driver model》第一版（当前阶段主要阅读资料，在先前的基础上，本次需要完成前八章）2．《Windows NT File System Internals - A Developers Guide》（资料1理解后可阅读，为后续章节做准备）3．《OSR White Papers》4、《Intel 64 and IA-32 Architectures Software Developer s Manual Volume 3A/B System Programming Guide》5．WinXXX部分源代码…6．《Kernel Debugging with WinDbg》（随WinDbg软件附带的文档）阅读基础：了解计算机结构体系、掌握用户模式下常用API调用、了解常用汇编指令。请从现在开始的一年时间里阅读50万字以上的驱动编程外文资料，彻底突破外文关。本章目的：初步掌握硬件驱动编程的基础知识，学习使用Windbg调试。初次阅读代码量在一万行以上的驱动程序。 二、问题的提出 xp下直接读写端口会发生什么事情呢？一个简单的测试程序如下： int main(int argc, char* argv[]){char result;asm {mov al, 0x10out 0x70, alin al, 0x71mov result, al}printf(%X, result);return 0;} 运行后发现程序弹出了异常，无法执行out指令，给出的提示为： 这是早已预料的结果。笔者搜索了一下，找到了《Direct Port IO and Windows NT》，欣欣然之下禁不住想让大家知道原来“不需要”写驱动也可以访问端口了。它究竟是何方神圣？原来这是一种称之为iopm的方法，它涉及了 CPU硬件理论里关于TS段的基础知识：通过修改I/O映射表，用户模式下的进程就具有了存取端口的权限。问题是如何修改I/O映射表？阅读了porttalk和winio的源代码后，发现所谓的iopm还是需要通过驱动代码修改映射表，此外你还需要修改当前进程的映射表偏移地址。当我们费力的写好近千行代码，换来的好处就是真的可以在用户模式下以较快的速度存取端口了。欣欣然的你不妨用文初给出的测试程序来检查一下成果： 如果把驱动编程想得这么的简单，那你就有些过于乐观了。现在尝试另一个端口，比如串口的0x3f8，看看有什么奇怪的事情发生？这次读出了0xff，那么0x3f9呢，还是0xff，一直读完串口的所有端口，结果都是0xff。假如我们首先用CreateFile来打开串口，怎么读出的值不再是0xff了，如果关闭了串口再来读一读，结果又是0xff了。Google或baidu后，发现串口原理的资料很少，换个思路来查，查询串口的主要芯片——从8250一直搜索到16550A，这下果然搜出了有价值的资料，如《Interfacing the Serial RS232 Port》，《串行输入输出接口》，《常用的输入输出接口芯片》，《UART 内部寄存器对应端口及用途》等。但这些资料只说明了一个问题——很久很久以前，在DOS下是如何发送串口指令的——却还是没有解决Windows下的问题。让我们再换一下思路。从DevView里看到串口驱动的基本情况，原来串口的PDO是ACPI。 阅读《Advanced Configuration and Power Interface Specification》，可知ACPI是微软和几个厂家制定的协议，不由得想起使用WINPE启动的时候选择了ACPI，结