linux驱动加载 动态加载 静态加载 自动加载

linux驱动加载 动态加载 静态加载 自动加载_luopandeng的博客-CSDN博客_linux驱动加载概述在Linux下可以通过两种方式加载驱动程序：静态加载和动态加载。静态加载就是把驱动程序直接编译进内核，系统启动后可以直接调用。动态加载利用了Linux的module特性，可以在系统启动后用insmod命令添加模块（.ko），在不需要的时候用rmmod命令卸载模块。驱动加载静态加载过程将模块的程序编译到Linux内核中，也就是咱们在编译内核时选择Y的模块，静态由do_initcall函数加载。先来看看initcall在哪里：核心进程（/init/main.c）...https://blog.csdn.net/luopandeng/article/details/113645994

概述
在咱们工作中，编译驱动，加载驱动时最常见的事。但是内核是如何加载驱动的，有些事编译到内核里面，有些事编译成ko,有些还能放到root下，让系统自动加载。

总的说来，在Linux下可以通过两种方式加载驱动程序：静态加载和动态加载。

静态加载就是把驱动程序直接编译进内核，系统启动后可以直接调用。动态加载利用了Linux的module特性，可以在系统启动后用insmod命令添加模块（.ko），在不需要的时候用rmmod命令卸载模块。

驱动加载
静态加载过程
 

将模块的程序编译到Linux内核中，也就是咱们在编译内核时选择Y的模块，静态由do_initcall函数加载。先来看看initcall在哪里：

核心进程（/init/main.c）

start_kernel（）//内核启动的入口，负责初始化调度，中断，内存，最后启动1号进程 和2号进程

     rest_init（）

          kernel_init（）//这是谁？ linux 1号进程，top一下系统就能找到1号进程了。

              do_basic_setup()

                    do_initcalls（）

do_initcalls中会定义的各个模块加载顺序，加载顺序分为16个等级，加载时按照16个等级依次加载内核驱动。关于每个等级的定义参考/include/linux/init.h。举个例子，在2.6.24的内核 中：gianfar_device使用的是arch_initcall，而gianfar_driver使用的是module_init，因为 arch_initcall的优先级大于module_init，所以gianfar设备驱动的device先于driver在总线上添加。

动态加载过程
将模块的程序编译成KO，也就是咱们在编译内核时选择M的模块，通过insmod

、modprobe 或者udev动态加载到内核中。 insmod加绝对路径/××.ko，而modprobe ××即可，不用加.ko或.o后缀，也不用加路径；最重要的一点是：modprobe同时会加载当前模块所依赖的其它模块。

来看看insmod都做了什么：

Insmod

    insmod_main

        bb_init_module

            init_module

                sys_init_module（进入系统调用）

                      sys_init_module()系统调用会调用module_init指定的函数进行模块的初始化，至此ko加载完成。

驱动匹配
硬件固件设计
以PCI为例，所有PCI硬件上必须设计一系列寄存器，PCI通过这些寄存器获取硬件信息，称为PCI配置空间，PCI配置空间格式如下：

PCI标准规定每个设备的配置寄存器组最多可以有256字节的连续空间，其中开头的64字节的用途和格式是标准的，成为配置寄存器组的“头部”，这样的头部又有两种，“0型”头部用于一般的PCI设备，“1型”头部用于PCI桥，无论是“0型”还是“1型”，其开头的16个字节的用途和格式是共同的。其中Device ID 和 Vendor ID 位于前4个字节。

在系统中运行LSPCI -NN,会得到类似如下输出：

 Ethernet controller [0200]: Intel Corporation 82545EM Gigabit Ethernet Controller (Copper) [8086:100f] (rev 01)

其中的8086是vendor ID，100f是Device ID。所以咱们常用的LSCPI实质上就是去硬件上读取硬件的寄存器值，并且显示出来。

软件驱动设计
每一个硬件设备都有Verdon ID, Device ID, SubVendor ID等信息。所以每一个设备驱动程序，必须说明自己能够为哪些Verdon ID, DevieceID, SubVendor ID的设备提供服务。以PCI设备为例，它是通过一个pci_device_id的数据结构来实现这个功能的。例如：RTL8139驱动的pci_device_id定义为：

Verdon ID可以理解为厂商ID，8086 代表Intel，1249代表三星等，Device ID可以理解为产品ID，每款产品的ID不同。上面的信息说明，Verdon ID为0x10EC, Device ID为0x8139, 0x8138的PCI设备(SubVendor ID和SubDeviceID为PCI_ANY_ID，表示不限制。)，都可以使用这个驱动程序(8139too)。

下面是内核设备与驱动匹配的代码：

自动加载过程
自动加载属于动态加载，加载的是ko文件，许多同学也没搞清楚，系统启动之后ko在什么时候，通过什么程序自动加载上的。

构建自动加载环境
 

编译内核时，通过make modules_install INSTALL_MOD_PATH=XXX，会将所有选项为M的模块编译为KO, 并且发布到xxx/lib/modules/uname-r/下面。在模块安装的时候，depmod会根据模块中的rtl8139_pci_tbl的信息，生成下面的信息，保存到/lib/modules/uname-r/modules.alias文件中，其内容如下：

alias pci:v000010ECd00008138sv*sd*bc*sc*i* 8139too alias pci:v000010ECd00008139sv*sd*bc*sc*i* 8139too ......

v后面的000010EC说明其Vendor ID为10EC，d后面的00008138说明Device ID为8139，而sv,和sd为SubVendor ID和SubDevice ID，后面的星号表示任意匹配。

另外在/lib/modules/uname-r/modules.dep文件中还保存这模块之间的依赖关系，其内容如下：

8139too.ko:mii.ko

modules.dep由depmod工具生成，在使用 modprobe xxx加载驱动时, modprobe需要借助modules.dep文件来分析模块之间的依赖关系，先加载依赖的ko，再加载真正需要加载的ko。

PCI扫描自动加载驱动
在内核启动过程中，总线驱动程序会会总线协议进行总线枚举(总线驱动程序总是集成在内核之中，不能够按模块方式加载，你可以通过make menuconfig进入Busoptions，这里面的各种总线，你只能够选择Y或N，而不能选择M.)，并且为每一个设备建立一个设备对象。每一个总线对象有一个kset对象，每一个设备对象嵌入了一个kobject对象，kobject连接在kset对象上，这样总线和总线之间，总线和设备设备之间就组织成一颗树状结构。当总线驱动程序为扫描到的设备建立设备对象时，会初始化kobject对象，并把它连接到设备树中，同时会调用kobject_uevent()把这个(添加新设备的)事件，以及相关信息(包括设备的VendorID,DeviceID等信息）通过netlink发送到用户态中。

来看看这个过程：

subsys_initcall (前面讲到过驱动的16级加载机制，subsys_initcall处于16级中的第8级，arch\x86\pci\legacy.c 参照内核4.19)

pci_legacy_init

pcibios_scan_root

pci_scan_root_bus

pci_scan_slot

pci_scan_single_device

pci_device_add

device_add

device_add有两个流程：

bus_probe_device 匹配内核中已有驱动
kobject_uevent 发消息到udev，让udev去/lib/modules/下面加载驱动
在用户态的udevd检测到这个事件，就可以根据这些信息，打开/lib/modules/uname-r/modules.alias文件，根据

alias pci:v000010ECd00008138sv*sd*bc*sc*i* 8139too

得知这个新扫描到的设备驱动模块为8139too。于是modprobe就知道要加载8139too这个模块了，同时modprobe根据 modules.dep文件发现，8139too依赖于mii.ko，如果mii.ko没有加载，modprobe就先加载mii.ko，接着再加载 8139too.ko。
————————————————

原文链接：https://blog.csdn.net/luopandeng/article/details/113645994

///Linux内核设备驱动模块自动加载机制

Linux内核设备驱动模块自动加载机制_smstong的博客-CSDN博客

摘要: 现在大多数硬件设备的驱动都是作为模块出现的，Linux启动过程中会自动加载这些模块，本文通过内核源码简要说明这个过程。

1 驱动模块本身包含设备商、设备ID号等详细信息
如果想让内核启动过程中自动加载某个模块该怎么做呢？最容易想到的方法就是到/etc/init.d/中添加一个启动脚本，然后在/etc/rcN.d/目录下创建一个符号链接，这个链接的名字以S开头，这内核启动时，就会自动运行这个脚本了，这样就可以在脚本中使用modprobe来实现自动加载。但是我们发现，内核中加载了许多硬件设备的驱动，而搜索/etc目录，却没有发现任何脚本负责加载这些硬件设备驱动程序的模块。那么这些模块又是如何被加载的呢？每一个设备都有Verdon ID, Device ID, SubVendor ID等信息。而每一个设备驱动程序，必须说明自己能够为哪些Verdon ID, DevieceID, SubVendor ID的设备提供服务。以PCI设备为例，它是通过一个pci_device_id的数据结构来实现这个功能的。例如：RTL8139的pci_device_id定义为：

static struct pci_device_id rtl8139_pci_tbl[] = {
{0x10ec, 0x8139, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
{0x10ec, 0x8138, PCI_ANY_ID, PCI_ANY_ID, 0, 0, RTL8139 },
......
}
MODULE_DEVICE_TABLE (pci, rtl8139_pci_tbl);
上面的信息说明，凡是Verdon ID为0x10EC, Device ID为0x8139, 0x8138的PCI设备(SubVendor ID和SubDeviceID为PCI_ANY_ID，表示不限制。)，都可以使用这个驱动程序(8139too)。

2 模块安装过程提取设备商、设备ID信息，并写入modules.alias文件
在模块安装的时候，depmod会根据模块中的rtl8139_pci_tbl的信息，生成下面的信息，保存到/lib/modules/uname-r/modules.alias文件中，其内容如下：

alias pci:v000010ECd00008138sv*sd*bc*sc*i* 8139too
alias pci:v000010ECd00008139sv*sd*bc*sc*i* 8139too
......

后面的000010EC说明其Vendor ID为10EC，d后面的00008138说明Device ID为8139，而sv,和sd为SubVendor ID和SubDevice ID，后面的星号表示任意匹配。另外在/lib/modules/uname-r/modules.dep文件中还保存这模块之间的依赖关系，其内容如下：

(这里省去了路径信息。)
8139too.ko:mii.ko
3 内核启动过程中，总线枚举时把读取的设备ID等信息发送到udevd，udevd根据modules.alias文件找到匹配的驱动模块，加载之。
在内核启动过程中，总线驱动程序会会总线协议进行总线枚举，并且为每一个设备建立一个设备对象。每一个总线对象有一个kset对象，每一个设备对象嵌入了一个kobject对象，kobject连接在kset对象上，这样总线和总线之间，总线和设备设备之间就组织成一颗树状结构。当总线驱动程序为扫描到的设备建立设备对象时，会初始化kobject对象，并把它连接到设备树中，同时会调用kobject_uevent()把这个(添加新设备的)事件，以及相关信息(包括设备的VendorID,DeviceID等信息。)通过netlink发送到用户态中。在用户态的udevd检测到这个事件，就可以根据这些信息，打开/lib/modules/uname-r/modules.alias文件，根据alias pci:v000010ECd00008138sv*sd*bc*sc*i* 8139too得知这个新扫描到的设备驱动模块为8139too。于是modprobe就知道要加载8139too这个模块了，同时modprobe根据 modules.dep文件发现，8139too依赖于mii.ko，如果mii.ko没有加载，modprobe就先加载mii.ko，接着再加载 8139too.ko。

4 实验
在你的shell中，运行：

# ps aux | grep udevd

root 25063 ...... /sbin/udevd --daemon
我们得到udevd的进程ID为25063，现在结束这个进程：

# kill -9 25063
然后跟踪udevd，在shell中运行：
# strace -f /sbin/udevd --daemon
这时，我们看到udevd的输出如下：
......
close(8) = 0
munmap(0xb7f8c000, 4096) = 0
select(7, [3 4 5 6], NULL, NULL, NULL
我们发现udevd在这里被阻塞在select()函数中。
select函数原型如下：

int select(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, struct timeval *timeout);
第一个参数：nfds表示最大的文件描述符号，这里为7(明明是6 ?)。
第二个参数：readfds为读文件描述符集合，这里为3,4,5,6.
第三个参数：writefds为写文件描述符集合，这里为NULL。
第四个参数：exceptfds为异常文件描述符集合，这里为NULL。
第五个参数：timeout指定超时时间，这里为NULL。
select函数的作用是：如果readfds中的任何一个文件有数据可读，或者witefds中的任何一个文件可以写入，或者exceptfds中的任何一个文件出现异常时，就返回。否则阻塞当前进程，直到上诉条件满足，或者因阻塞时间超过了timeout指定的时间，当前进程被唤醒，select返回。

所以，在这里udevd等待3,4,5,6这几个文件有数据可读，才会被唤醒。现在，到shell中运行：

# ps aux | grep udevd
root 27615 ...... strace -o /tmp/udevd.debug -f /sbin/udevd --daemon
root 27617 ...... /sbin/udevd --daemon
udevd的进程id为27617，现在我们来看看select等待的几个文件：

# cd /proc/27615/fd
# ls -l

udevd的标准输入，标准输出，标准错误全部为/dev/null.
0 -> /dev/null
1 -> /dev/null
2 -> /dev/null

udevd在下面这几个文件上等待。
3 -> /inotify
4 -> socket:[331468]
5 -> socket:[331469]
6 -> pipe:[331470]
7 -> pipe:[331470]
由于不方便在运行中插入一块8139的网卡，因此现在我们以一个U盘来做试验，当你插入一个U盘后，你将会看到strace的输出，从它的输出可以看到 udevd在select返回后，调用了modprobe加载驱动模块，并调用了sys_mknod，在dev目录下建立了相应的节点。

execve("/sbin/modprobe", ["/sbin/modprobe", "-Q", "usb:v05ACp1301d0100dc00dsc00dp00"...]
......
mknod("/dev/sdb", S_IFBLK|0660, makedev(8, 16)) = 0
......
这里modprobe的参数"usb:v05AC..."对应modules.alias中的某个模块。

可以通过udevmonitor来查看内核通过netlink发送给udevd的消息，在shell中运行：

# udevmonitor --env
然后再插入U盘，就会看到相关的发送给udevd的消息。
== 内核处理过程 ==：

这里我们以PCI总线为例，来看看在这个过程中，内核是如何处理的。当PCI总线驱动程序扫描到一个新的设备时，会建立一个设备对象，然后调用 pci_bus_add_device()函数，这个函数最终会调用kobject_uevent()通过netlink向用户态的udevd发送消息。

int pci_bus_add_device(struct pci_dev *dev)
{
int retval;
retval = device_add(&dev->dev);

......

return 0;
}
device_add()代码如下：

int device_add(struct device *dev)
{
struct device *parent = NULL;

dev = get_device(dev);

......

error = bus_add_device(dev);
if (error)
goto BusError;
kobject_uevent(&dev->kobj, KOBJ_ADD);
......
}
device_add()在准备好相关数据结构后，会调用kobject_uevent()，把这个消息发送到用户空间的udevd。

int kobject_uevent(struct kobject *kobj, enum kobject_action action)
{
return kobject_uevent_env(kobj, action, NULL);
}
int kobject_uevent_env(struct kobject *kobj, enum kobject_action action, char *envp_ext[])
{
struct kobj_uevent_env *env;
const char *action_string = kobject_actions[action];
const char *devpath = NULL;
const char *subsystem;
struct kobject *top_kobj;
struct kset *kset;
struct kset_uevent_ops *uevent_ops;
u64 seq;
int i = 0;
int retval = 0;

......

/* default keys */
retval = add_uevent_var(env, "ACTION=%s", action_string);
if (retval)
goto exit;
retval = add_uevent_var(env, "DEVPATH=%s", devpath);
if (retval)
goto exit;
retval = add_uevent_var(env, "SUBSYSTEM=%s", subsystem);
if (retval)
goto exit;

/* keys passed in from the caller */
if (envp_ext) {
for (i = 0; envp_ext[i]; i++) {
retval = add_uevent_var(env, envp_ext[i]);
if (retval)
goto exit;
}
}

......

/* 通过netlink发送消息，这样用户态的udevd进程就会从select()函数返回，并做相应的处理。 */
#if defined(CONFIG_NET)
/* send netlink message */
if (uevent_sock) {
struct sk_buff *skb;
size_t len;

/* allocate message with the maximum possible size */
len = strlen(action_string) + strlen(devpath) + 2;
skb = alloc_skb(len + env->buflen, GFP_KERNEL);
if (skb) {
char *scratch;

/* add header */
scratch = skb_put(skb, len);
sprintf(scratch, "%s@%s", action_string, devpath);

/* copy keys to our continuous event payload buffer */
for (i = 0; i < env->envp_idx; i++) {
len = strlen(env->envp[i]) + 1;
scratch = skb_put(skb, len);
strcpy(scratch, env->envp[i]);
}

NETLINK_CB(skb).dst_group = 1;
netlink_broadcast(uevent_sock, skb, 0, 1, GFP_KERNEL);
}
}
#endif

......
return retval;
}

5 思考
现在我们知道/dev目录下的设备文件是由 udevd负责建立的，但是在内核启动过程中，需要mount一个根目录，通常我们的根目录是在硬盘上，比如：/dev/sda1，但是硬盘对应的驱动程序没有加载前，/dev/sda1是不存在的， 如果没有/dev/sda1，就不能通过mount /dev/sda1 /来挂载根目录。另一方面udevd是一个可执行文件，如果连硬盘驱动程序到没有加载，根目录都不存在，udevd就不能运行。如果udevd不能运行，那么就不会自动加载磁盘驱动程序，也就不能自动创建/dev/sda1。这不是死锁了吗？那么你的Linux是怎么启动的呢？

————————————————
版权声明：本文为CSDN博主「smstong」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/smstong/article/details/9836589