1、为何/sys中driver的uevent文件只写?
该文件用于调试udev或者人为引起uevent的发送,执行类似:
$ echo add > /sys/…/driver/…/uevent
命令时,会模拟一个uevent(ADD)事件,在kernel中,该文件的属性设置为只写。
小结:
bus、driver的uevent文件只写
device(包括bus设备)的uevent文件可读可写
2、用户空间中驱动模块的处理逻辑:
核心处理函数是handle_module_loading() –>
get_module_dep(modalias, NULL, 1, MODULES_BLKLST, &dep);
parse_alias_to_list("/lib/modules/modules.alias", &alias_list); // 解析/lib/modules/modules.alias文件中模块别名到一个特定的链表alias_list
parse_blacklist_to_list(blacklist, &extra_blacklist); // 解析/lib/modules/modules.blacklist所指定的模块黑名单到一个特定的 链表extra_blacklist
load_dep_file(dep_name); // 加载/lib/modules/modules.dep中的模块依赖清单到内存
get_module_name_from_alias(module_name, &module_aliases, &alias_list) // 检查从uevent接收到的模块名称是否是一个别名
validate_module(module_name, dep_file, &extra_blacklist, dep); // 检查该模块是否在黑名单中
get_mod_args() // 遍历lmod_args链表,从中找到与当前模块匹配的模块参数(用名称进行匹配)
insmod_s() // 加载模块
3、系统启动时,设备和驱动的一般加载过程:
1>系统启动后,注册设备,创建/sys相关文件
PS:注册设备时,会发送uevent(ADD) ,但是此时/sbin/ueventd进程尚未运行
2>执行/sbin/ueventd进程,在用户空间利用/sys/devices/xx/uevent文件,模拟设备的热插拔事件uevent(ADD)
3>用户空间收到该uevent(ADD)事件,加载对应驱动
4、wlan设备在kernel中的存在实体既是sdio_func,又是platform_device,
dhd_module_init()是wlan驱动注册的入口:
1>platform_device的驱动注册
dhd_module_init()
wl_android_wifictrl_func_add()
wifi_add_dev()
platform_driver_register(&wifi_device);
platform_driver_register(&wifi_device_legacy);
2>驱动抽象以及匹配ID(ACPI和设备树)
static struct platform_driver wifi_device = {
.probe = wifi_probe,
.remove = wifi_remove,
.suspend = wifi_suspend,
.resume = wifi_resume,
.driver = {
#ifdef CONFIG_ACPI
.acpi_match_table = ACPI_PTR(bcm_acpi_id),
#endif
.name = "wlan",
.of_match_table = wifi_device_dt_match,
}
该文件用于调试udev或者人为引起uevent的发送,执行类似:
$ echo add > /sys/…/driver/…/uevent
命令时,会模拟一个uevent(ADD)事件,在kernel中,该文件的属性设置为只写。
小结:
bus、driver的uevent文件只写
device(包括bus设备)的uevent文件可读可写
2、用户空间中驱动模块的处理逻辑:
核心处理函数是handle_module_loading() –>
get_module_dep(modalias, NULL, 1, MODULES_BLKLST, &dep);
parse_alias_to_list("/lib/modules/modules.alias", &alias_list); // 解析/lib/modules/modules.alias文件中模块别名到一个特定的链表alias_list
parse_blacklist_to_list(blacklist, &extra_blacklist); // 解析/lib/modules/modules.blacklist所指定的模块黑名单到一个特定的 链表extra_blacklist
load_dep_file(dep_name); // 加载/lib/modules/modules.dep中的模块依赖清单到内存
get_module_name_from_alias(module_name, &module_aliases, &alias_list) // 检查从uevent接收到的模块名称是否是一个别名
validate_module(module_name, dep_file, &extra_blacklist, dep); // 检查该模块是否在黑名单中
get_mod_args() // 遍历lmod_args链表,从中找到与当前模块匹配的模块参数(用名称进行匹配)
insmod_s() // 加载模块
3、系统启动时,设备和驱动的一般加载过程:
1>系统启动后,注册设备,创建/sys相关文件
PS:注册设备时,会发送uevent(ADD) ,但是此时/sbin/ueventd进程尚未运行
2>执行/sbin/ueventd进程,在用户空间利用/sys/devices/xx/uevent文件,模拟设备的热插拔事件uevent(ADD)
3>用户空间收到该uevent(ADD)事件,加载对应驱动
4、wlan设备在kernel中的存在实体既是sdio_func,又是platform_device,
dhd_module_init()是wlan驱动注册的入口:
1>platform_device的驱动注册
dhd_module_init()
wl_android_wifictrl_func_add()
wifi_add_dev()
platform_driver_register(&wifi_device);
platform_driver_register(&wifi_device_legacy);
2>驱动抽象以及匹配ID(ACPI和设备树)
static struct platform_driver wifi_device = {
.probe = wifi_probe,
.remove = wifi_remove,
.suspend = wifi_suspend,
.resume = wifi_resume,
.driver = {
#ifdef CONFIG_ACPI
.acpi_match_table = ACPI_PTR(bcm_acpi_id),
#endif
.name = "wlan",
.of_match_table = wifi_device_dt_match,
}