详解Linux操作系统设备驱动兼容性

　　在核心的版本2.1，Linux的Intel移植对虚拟内存有了一个成熟的视图。早些的版本的内存管理一直使用“分段”的方法，这是从核心生命期的开始时期继承下来的。这个改变并不影响驱动程序代码，但不管怎样，还是值得一说的。新的规则与Linux的其它移植匹配的起来。虚拟地址空间被构造成核心居于非常高的地址（从3GB往上），而用户地址空间在0-3GB范围。当一个进程运行在“管态”时，它可以访问两个空间。另一方面，当它运行在“用户态”时，它不能访问核心空间，因为属于核心的页被标记为“管理员”页，处理器阻止了对它们的访问。

　　这种内存布局有助于取消旧的memcpy_to_fs一类的函数，因为已经没有FS段了。核心空间和用户空间使用同一个“段”，其区别在于CPU所在的优先级。

　　处理核心空间错误

　　Linux核心的2.1版本对从核心空间处理段错误的能力有一个极大的增强。本章里，我准备对其原则给一个快速的概述。新机制对源码的影响在“访问用户空间”中已经描述过。

　　如前面所提到过的，核心的最近版本充分利用了ELF二进制格式，特别是考虑到它的在编译的文件中定义用户定义的节的能力。编译器和链接器保证属于同一节的代码段在可执行文件中一定是连续的，因此当文件被装载时，在内存中也是连续的。例外处理是通过在核心可执行映象(vmlinux)中定义两个新节实现的。每次当源码通过copy_to_user, put_user, 或其读取的对应者访问用户空间时，一些代码被加到这两个节中。尽管这看起来是不可忽略的开销，这个新机制的一个结果是不再需要使用一个昂贵的verify_area。而且，如果使用的用户地址是正确的，计算流将不会有一个跳转。当被访问的用户地址是无效的时，硬件发出一个页面错。错误处理程序（在体系结构特定的源码树中的do_page_fault）确认这个错误是一个“不正确的地址”错（与“页不存在”相对），并使用下面的ELF节进行适当的动作：__ex_table这节是个指针对的表。每对的第一个指针指向一个可能因错误的用户空间地址而失败的指令，第二个值指向一个地址，处理器将在那里找到几条的指令来处理这个错误。..fixup这节包含指令，处理在__ex_table中描述的所有可能的错误。这个表中每对的第二个指针指向居于.fixup中的代码。

　　头文件负责构造所需的ELF节。访问用户空间的每个函数（如put_user）扩展为汇编指令，它将指针加到__ex_table并处理.fixup中的错。当代码运行时，实际的执行路径有一下步骤组成：用于函数“返回值”的处理器寄存器被初始化为0（也就是没有错误），数据被传送，返回知被传回调用者。一般的操作的确非常快。如果一个异常发生，do_page_fault打印一条消息，查看__ex_table，跳转到.fixup，这里设置返回值为-EFAULT，然后跳转到访问用户空间的指令后位置。

　　新的行为可以用faulty（在v2.1/misc-modules目录）模块来检验。faulty在第四章“调试技巧”中“调试系统错误”一节描述。faulty的设备结点通过读取一个短缓冲区界外来传送数据到用户空间，这样当读取一个在模块页以上的地址时，会导致一个页面错。有趣的是注意到这个错误依赖于使用核心空间中的一个不正确地址，而大多数情况下异常是有出错的用户空间地址造成的。当在PC上用cat命令读faulty时，下面的消息被打印在控制台上：

　　前一行是由faulty的read方法打印的，而后者是由错误处理程序打印的。第一个数字是错误指令的地址，而第二个是修正代码（在.fixup节中）的地址。

　　其它改变

　　在2.0和2.1.43之间还有其它一些不同。以我的观点，它们不需要给予特别的关注，因此我将迅速地概述一下。proc_register_dynamic在2.1.29中消失了。最近的核心对每个/proc文件使用proc_register接口；如果结构proc_dir_entry的low_ino域是0，那么会被分配一个动态的inode号。当为2.1.29或更新的核心编译时，头文件sysdep-2.1.h象proc_register一样定义proc_register_dynamic；这个在注册的proc_dir_entry结构以0为inode号时是可行的。在网络接口驱动程序领域，rebuild_header设备方法从2.1.15起有一个新的原型。如果你只开发以太网驱动程序，你不会关心这个不同，因为以太网驱动程序不实现它们自己的方法；它们依赖于通用的以太网实现。当旧的实现需要时，头文件sysdep-2.1定义了宏__USE_OLD_REBUILD_HEADER__。示例模块snull显示了如何使用这个宏，但每必要在这

　　里给出。

　　网络代码的另一个改变影响了结构enet_statistics，它从2.1.25起不再存在。代替它的是一个新结构net_device_stats，它在中定义，而不是。新结构与旧结构类似，但是多了两个域存储字节计数器：unsigned longrx_bytes, tx_bytes；一个全特征的网络接口驱动程序应该与rx_packets和tx_packets一道增加这些计数器，尽管一个快速的计划可能要抛弃这些计数器。核心头文件将enet_statistics（老结构的名字）定义为net_device_stats（新结构的名字）以方便已有驱动程序的可移植性。

　　最后，我需要指出current不再是个全局变量x86, Alpha,以及Sparc的核心移植使用了聪明的技巧将current存在处理器中。这样核心的开发者努力又挤出了几个CPU周期。这个技巧避免了大量的内存访问，有时还能释放一个通用目的寄存器；编译器经常分配处理器寄存器来高速缓存几个经常访问的内存位置，而current是经常访问的。在不同的移植中使用了不同的技巧以优化访问。Alpha和Sparc版本使用一个处理器寄存器（编译器优化不使用的一个）来存储current。而Intel处理器有有限数目的寄存器，编译器可以使用它们所有；在这种情况下技巧包括将结构task_struct和核心栈页存储在连续的虚存页内。这允许current指针被“编码”在栈指针中。对每个Linux支持的平台，头文件current.h>给出了实际选择的实现。象所有重要的软件一样，Linux一直在改变着。如果你想为这个最新的、最伟大的核心写驱动程序，你需要保持跟上核心的发展。尽管处理不兼容性看起来可能很困难，我们发现两点特性：首先，主要的程序设计技巧一直在那里，不太可能改变（至少不常）；第二，每次改变都变得更好了，经常使你在将来的开发中需要的工作越来越少。