什么是上层驱动和下层驱动？？

Windows的设备驱动框架中的上层与下层模块

在Windows的设备驱动框架中，下层模块向上层模块提供一个数据结构指针。但是，上层模块并不直接从这个数据结构获取具体的函数指针，更不直接使用这些函数指针调用下层模块中的函数；而是通过一些由内核提供的函数下达“I/O请求包”即IRP，间接地调用下层模块提供的函数，要求其执行某种 *** 作。这就好像是向内核下一个定单，定单中告诉内核要由哪一个下层模块执行何种 *** 作。另一方面，对于建立了形式“堆叠”的设备驱动，上层模块在运行中通常也没有如何“找到”下层模块的问题，甚至根本就不必知道其下一层是什么模块或什么设备，模块之间已在建立形式堆叠的时候固定连接好了。此时上层模块所获得的是哪一个下层模块的指针，取决于同一个堆叠中各个模块的装载次序，实际上取决于系统的配置，而相关的配置信息则最终来自相关的inf文件，这些信息保存在集中的数据库“注册表（Registry）”中。这样就为通过系统配置改变具体设备驱动堆叠的结构提供了更大的灵活性，主要体现在：

更容易在堆叠的下层实现“重定向”，即把上层模块嫁接到不同的下层模块上；

更容易在堆叠内部插入以“过滤驱动对象（FiDO）”为代表的“过滤模块”。

最后，设备驱动模块不是在真空中运行，需要得到内核的支持，需要由内核为其构筑起一个运行环境，这个环境的主体就是内核导出函数，此外还有一些全局的变量和数据结构。这就是Windows的“设备驱动开发包”DDK中所定义（更准确地说是“声明”）的函数和变量。

事物都是在发展的，Windows的设备驱动框架也不是一开始就这样，更不是永远这样。前面所讲的是为实现“即插即用”所必须要有的要素，主要就是模块的动态装载以及模块堆叠的形成。有了这些要素，包括即插即用在内的分层设备驱动就可以实现了，但是当然还可以有一些附加的要求。从Windows 98和Windows 2000开始，微软定义了一种（在当时是）新的设备驱动框架，称为WDM即“Windows设备驱动模型（Windows Driver Model）”。WDM要求设备驱动模块除满足PnP的需要外，还必须提供两方面的功能支持：

对于WMI的支持。WMI是“Windows管理手段（Windows Management Instrumentation）”的缩写。WMI与“简单网络管理规程”SNMP相似，要求每台Windows主机都能应“管理器（Manager）”的要求提供包括设备驱动在内的各种状态和统计信息。这些信息从哪儿来呢？对于设备驱动，当然得要由相应的设备驱动模块提供。

对于电源管理的支持。有些外设能耗不小，如果有一段较长的时间没有实际使用，就没有理由不将其转入某种“省电模式”。即使是能耗不大的外设，在节能成为一个环保问题的今天，也应该在不用时使其转入省电模式。这就是电源管理要达到的目的之一。所以，微软把支持电源管理列为WDM的要素之一。

总之，“老式”的设备驱动（在形式上）是不分层、不堆叠的；如果形式上分层并堆叠，在微软的术语中就称为“PnP设备驱动”。而WDM设备驱动，则是至少在形式上满足了上述两项附加条件的PnP设备驱动。对WMI的支持和电源管理的重要性当然不容低估，但是对于我们理解Windows的设备驱动框架却并非技术关键，所以后面的叙述将集中在框架的构成与实现，而忽略这两个方面。正因为这样，我们将称之为“Windows设备驱动框架”而不是“WDM”，以免混淆。

注意看这个文件

sysdeps/unix/sysv/linux/syscallslist

里面记录着系统调用的名字和一些属性，具体我也没有研究过，不懂。

再看select的实现，很让人惊讶，一旦使用，结果就是“报错“。

int

__select (nfds, readfds, writefds, exceptfds, timeout)

int nfds;

fd_set readfds;

fd_set writefds;

fd_set exceptfds;

struct timeval timeout;

{

__set_errno (ENOSYS);

return -1; 

}

libc_hidden_def (__select)

stub_warning (select)

weak_alias (__select, select)

这是因为glibc并没有实现系统调用，而是调用系统调用，

更进一步，连调用系统调用都没有一个个实现，而是使用了通用的办法，

理由很简单，所有的系统调用在linux内核头文件里都能找到，

所有的系统调用参数类型就那么几种，参数个数也是有限的，

因此没有必要针对所有的系统调用一一封装，

于是就有了这个list文件，自动生成调用系统调用的函数，

如果生成失败，也就是你看到的“报错”。

符号是有强弱的，当自动生成成功的时候，“报错”的弱符号就被忽略了。

当你在glibc中找到一个系统调用的封装源码，是以下原因，

编译的目标系统不支持这个系统调用，所以自己用另一种方式实现了。

2 这个系统调用无法使用通用的自动生成方式生成，用特化的方式覆盖。

3 针对这个系统调用做了特别的优化。

4 其它可能的原因。

具体可以留意

SYSCALL, PSEUDO, DO_CALL, INLINE_CALL 等名字

这两个文件是重点所在

sysdeps/unix/i386/sysdeph

sysdeps/unix/i386/sysdepS

要搞清楚具体的自动生成过程，恐怕得研究glibc自身的编译过程了

在内核中通过/proc/kallsyms获得符号的地址

Linux内核符号表/proc/kallsyms的形成过程

/scripts/kallsymsc负责生成Systemmap

/kernel/kallsymsc负责生成/proc/kallsyms

/scripts/kallsymsc解析vmlinux(tmp_vmlinux)生成kallsymsS(tmp_kallsymsS)，然后内核编译过程中将kallsymsS(内核符号表)编入内核镜像uImage

内核启动后/kernel/kallsymsc解析uImage形成/proc/kallsyms

/proc/kallsyms包含了内核中的函数符号(包括没有EXPORT_SYMBOL)、全局变量(用EXPORT_SYMBOL导出的全局变量)

如何将内核中的函数、全局变量、静态变量都导出到/proc/kallsyms

查看内核 使用 uname -a