Linux那些事儿 之 戏说USB(8)从这里开始

USB core从USB子系统的初始化开始，我们也需要从那里开始，它们在文件drivers/usb/core/usb.c

subsys_initcall(usb_init);
module_exit(usb_exit);

我们看到一个subsys_initcall，复旦人甲说它也是一个宏，我们可以把它理解为module_init，只不过因为这部分代码比较核心，开发者们把它看作一个子系统，而不仅仅是一个模块，这也很好理解，usbcore这个模块它代表的不是某一个设备，而是所有usb设备赖以生存的模块，Linux中，像这样一个类别的设备驱动被归结为一个子系统。比如pci子系统，比如scsi子系统，基本上，内核源码中drivers/目录下面第一层的每个目录都算一个子系统，因为它们代表了一类设备。subsys_initcall(usb_init)的意思就是告诉我们usb_init是我们真正的初始化函数，而usb_exit()将是整个usb子系统的结束时的清理函数，于是我们就从usb_init开始看起。

既然复旦人甲都这么说了，那咱们就从usb_init开始看起吧。至于子系统在内核里具体的描述，牵涉到linux设备模型了，可以去看ldd3，或者更详细的。目前来说，我们只需要知道子系统通常显示在sysfs分层结构中的顶层，比如块设备子系统对应/sys/block，当然也不一定，usb子系统对应的就是/sys/bus/usb。

drivers/usb/core/usb.c

static int __init usb_init(void)
{
	int retval;
	if (nousb) {
		pr_info("%s: USB support disabled\n", usbcore_name);
		return 0;
	}

	retval = usb_debugfs_init();
	if (retval)
		goto out;

	usb_acpi_register();
	retval = bus_register(&usb_bus_type);
	if (retval)
		goto bus_register_failed;
	retval = bus_register_notifier(&usb_bus_type, &usb_bus_nb);
	if (retval)
		goto bus_notifier_failed;
	retval = usb_major_init();
	if (retval)
		goto major_init_failed;
	retval = usb_register(&usbfs_driver);
	if (retval)
		goto driver_register_failed;
	retval = usb_devio_init();
	if (retval)
		goto usb_devio_init_failed;
	retval = usb_hub_init();
	if (retval)
		goto hub_init_failed;
	retval = usb_register_device_driver(&usb_generic_driver, THIS_MODULE);
	if (!retval)
		goto out;

	usb_hub_cleanup();
hub_init_failed:
	usb_devio_cleanup();
usb_devio_init_failed:
	usb_deregister(&usbfs_driver);
driver_register_failed:
	usb_major_cleanup();
major_init_failed:
	bus_unregister_notifier(&usb_bus_type, &usb_bus_nb);
bus_notifier_failed:
	bus_unregister(&usb_bus_type);
bus_register_failed:
	usb_acpi_unregister();
	usb_debugfs_cleanup();
out:
	return retval;
}

看到上面定义里的__init标记没，写过驱动的应该不会陌生，它对内核来说就是一种暗示，表明这个函数仅在初始化期间使用，在模块被装载之后，它占用的资源就会释放掉用作它处。
对__init的定义在include/linux/init.h里

#define __init		__section(.init.text) __cold notrace

好像这里的疑问要更多，不过与 __init 相比，这点辛苦算什么，我会在它强大的精神支持下尽量说清楚的。Linux内核代码使用了大量的GNU C扩展，以至于GNU C成为能够编译内核的唯一编译器，GNU C的这些扩展对代码优化、目标代码布局、安全检查等方面也提供了很强的支持。GNU C支持十几个属性，section是其中的一个，我们查看gcc的手册可以看到下面的描述
‘section ("section-name")'　　 Normally, the compiler places the code it generates in the `text'
section.　Sometimes, however, you need additional sections, or you
need certain particular functions to appear in special sections.
　　 The `section' attribute specifies that a function lives in a
　　 particular section.　For example, the declaration:

　　　　　extern void foobar (void) __attribute__ ((section ("bar")));

　　 puts the function ‘foobar' in the ‘bar' section.　
　
Some file formats do not support arbitrary sections so the
　　 ‘section' attribute is not available on all platforms.　If you
　　 need to map the entire contents of a module to a particular
　　 section, consider using the facilities of the linker instead.

通常编译器将函数放在.text节，变量放在.data 或 .bss 节，使用section属性，可以让编译器将函数或变量放在指定的节中。那么前面对__init的定义便表示将它修饰的代码放在 .init.text 节。连接器可以把相同节的代码或数据安排在一起，比如 __init 修饰的所有代码都会被放在 .init.text 节里，初始化结束后就可以释放这部分内存。
那内核又是如何调用到这些 __init 修饰的初始化函数那？
要回答这个问题，还需要回顾一下上面938行的代码，那里已经提到subsys_initcall也是一个宏，它也在include/linux/init.h里定义

#define subsys_initcall(fn)		__define_initcall(fn, 4)

这里又出现了一个宏__define_initcall，它是用来将指定的函数指针fn放到initcall.init节里，也在include/linux/init.h文件里定义，这里就不多说了，有那点意思就可以了。而对于具体的subsys_initcall宏，则是把fn放到.initcall.init的子节.initcall4.init里。要弄清楚.initcall.init、.init.text和.initcall4.init这样的东东，我们还需要了解一点内核可执行文件相关的概念。

内核可执行文件由许多链接在一起的对象文件组成。对象文件有许多节，如文本、数据、init 数据、bass 等等。这些对象文件都是由一个称为链接器脚本的文件链接并装入的。这个链接器脚本的功能是将输入对象文件的各节映射到输出文件中；换句话说，它将所有输入对象文件都链接到单一的可执行文件中，将该可执行文件的各节装入到指定地址处。 vmlinux.lds是存在于 arch/<target>/ 目录中的内核链接器脚本，它负责链接内核的各个节并将它们装入内存中特定偏移量处。

涉及到的东西越来越多了是吧，先深呼吸，平静一下，坚定而又勇敢的打开arch/arm/kernel/vmlinux.lds文件，你就会见到前所未见的景象。我可以负责任的说，要看懂这个文件是需要一番功夫的，不过大家都是聪明人，聪明人做聪明事，所以你需要做的只是搜索initcall.init，然后便会看到似曾相识的内容

__initcall_start = .;
 *(.initcallearly.init) __early_initcall_end = .;
 *(.initcall0.init) *(.initcall0s.init)
 *(.initcall1.init) *(.initcall1s.init)
 *(.initcall2.init) *(.initcall2s.init)
 *(.initcall3.init) *(.initcall3s.init)
 *(.initcall4.init) *(.initcall4s.init)
 *(.initcall5.init) *(.initcall5s.init)
 *(.initcallrootfs.init)
 *(.initcall6.init) *(.initcall6s.init)
 *(.initcall7.init) *(.initcall7s.init)
 __initcall_end = .;

这里的 __initcall_start 指向.initcall.init节的开始，__initcall_end指向它的结尾。而.initcall.init节又被分为了7个子节，分别是
.initcall1.init
.initcall2.init
.initcall3.init
.initcall4.init
.initcall5.init
.initcall6.init
.initcall7.init
我们的subsys_initcall宏便是将指定的函数指针放在了 .initcall4.init 子节。其它的比如 core_initcall 将函数指针放在 .initcall1.init 子节，device_initcall 将函数指针放在了 .initcall6.init 子节等等，都可以从include/linux/init.h文件找到它们的定义。各个字节的顺序是确定的，即先调用.initcall1.init中的函数指针再调用.initcall2.init中的函数指针，等等。__init 修饰的初始化函数在内核初始化过程中调用的顺序和.initcall.init节里函数指针的顺序有关，不同的初始化函数被放在不同的子节中，因此也就决定了它们的调用顺序。

至于实际执行函数调用的地方，就在/init/main.c文件里，内核的初始化么，不在那里还能在哪里，里面的do_initcalls函数会直接用到这里的__initcall_start、__initcall_end来进行判断，不多说了。我们的思念已经入滔滔江水泛滥成灾了，还是回到久违的usb_init函数吧。