Linux kernel (13)-Subsystem initialization with PCI subsystem as an example

The distribution of this map by Kconfig, the PCI code should be distributed in two places, Drivers/pci and Arch/i386/pci, Taiwan belong to a China, whether drivers/pci there, or arch/i386/ PCI There, but also belong to a PCI subsystem, in the spirit of a Chinese principle, we want to co-ordinate the comprehensive investigation of the code located in two places, so, these far beyond the five-digit code to see the right look at the horizontal look at the vertical look at all appear so grim horror, but people say is also the entire PCI subsystem, Like a walk on the catwalk sister Furong and Yang two car that the same, looks scary but also has a connotation, can let a person three eyes two eyes few words to see through to say thoroughly?

Well, now let's take a broad look at the two-place code, according to the previous content can be inferred for the USB, PCI subsystem should have a subsys_initcall such a portal, we have to find it first. Zhu Deyong in the "about work this matter" said, to spend half a day to find the entrance, spend the rest of the life to find the exit. Find the entrance for our life, to see the kernel code this matter is extremely important, of course, looking for Subsys_initcall this entrance is not spent the first half of the time. The bottom of the son I will find the list, why say "column" Come out? Is there a lot more? You guessed right, PCI this edge entrance particularly many, and is premeditated organized into series, not only have subsys_initcall, also have Arch_initcall, Postcore_initcall and so on.

file Function Entry memory location
Arch/i386/pci/acpi.c pci_acpi_init Subsys_initcall. Initcall4.init
Arch/i386/pci/common.c pcibios_init Subsys_initcall. Initcall4.init
Arch/i386/pci/i386.c pcibios_assign_resources Fs_initcall. Initcall5.init
Arch/i386/pci/legacy.c pci_legacy_init Subsys_initcall. Initcall4.init
Drivers/pci/pci-acpi.c acpi_pci_init Arch_initcall. Initcall3.init
Drivers/pci/pci-driver.c pci_driver_init Postcore_initcall. Initcall2.init
DRIVERS/PCI/PCI-SYSFS.C pci_sysfs_init Late_initcall. Initcall7.init
Drivers/pci/pci.c pci_init Device_initcall. Initcall6.init
Drivers/pci/probe.c pcibus_class_init Postcore_initcall. Initcall2.init
DRIVERS/PCI/PROC.C pci_proc_init __initcall. Initcall6.init
Arch/i386/pci/init.c pci_access_init Arch_initcall. Initcall3.init

Look at that in the mouth, the shape of the different kinds of xxx_initcall people dazzling, really do not know where to start, should keso that sentence: All the pain from the choice, so-called happiness, is no choice. Like the USB subsystem as a simple subsys_initcall, no choice, silly strong know how to go. But you are lost and few moments, but don't really get in the way. To know "How many things, never anxious, the world turns, the time is forced." 10,000 years too long, seize. The Sihai cloud water fury, continental concussion shock. To see all the entrance, all invincible. "We must seize see all the entrances."

We already know that calls to these xxx_initcall functions must be in a certain order, Call again in. Initcall1.init. In Initcall2.init, it is obvious that the list should be called first. Two functions Pcibus_class_init and Pci_ in the. Initcall2.init Sub-section Driver_init. Now the problem arises, which of the functions in the same sub-section, such as Pcibus_class_init and Pci_driver_init, is the first to be called? Of course, you can say that the front-edge address will be called first, which is truth, because the Do_initcalls function is implemented as a for loop back and forth on the address where the. Initcall.init is located. But how do you know the function of the same sub-section which is in the front and which one is behind?

In other words, first look at the passage of GCC using the GNU Compiler collection:

The linker searches and processes libraries and object files in the order they is specified. Thus, ' Foo.o-lz bar.o ' searches library ' z ' after file ' foo.o ' but before ' bar.o '.

After reading this passage, hope will hear you say: I enlightened! I would like to see you turn out the Drivers/pci/makefile file, look at the bottom of these two lines

5 obj-y + = ACCESS.O bus.o probe.o remove.o pci.o QUIRKS.O/
6 pci-driver.o search.o pci-sysfs.o rom.o SETUP-RES.O

PROBE.O in front of PCI-DRIVER.O, the Pcibus_class_init function in probe.c is also called before pci-driver.c function in Pci_driver_init. Again

Here's a word for you, documents/kbuild/makefile.txt in 3.2:

The order of files in $ (obj-y) is significant.

For pcibus_class_init functions and Pci_driver_init functions, the order of links that are located at the same directory location can be specified by the directory makefile file, and for Acpi_pci_ in the. Initcall3.init Sub-section The init function and the Pci_access_init function do not use this method.

Acpi_pci_init in the Drivers/pci/pci-acpi.c file, and Pci_access_init in the arch/i386/pci/init.c file, they are not at all under the same directory, so the front edge judgment pcibus_ The sequence of Class_init and Pci_driver_init does not apply, so what can we do to find out the order of them? See Boutique how to say: "Yesterday is the Wuyi Labor Day, but the whole country in amplification false most people do not work." It can be seen that the best way to celebrate a thing is not to do it. The best way to celebrate the World Cup, for example, is not to go to the World Cup – which the Chinese team has almost always done. For example, the best way to celebrate Valentine's Day is not to find a lover-so many Chinese men have made Valentine's Day (February 13) the day before Valentine's Day. "According to him, the best way to identify the order between the two functions is to not take care of their order, I can soldiers of the point of a random one out first, but as a very clear responsibility and mission of Gen Y, I still decided to explore their order."

In fact, this problem can be translated into ARCH/I386/PCI below the makefile and DRIVERS/PCI below the makefile who first who after the problem, to the large side, is how the kernel is built, that is, the problem of Kbuild.

There are three main types of Makefile in the kernel: the first is the Makefile in the root directory, although there is only one, but the status is far above the other Makefile, which defines all the variables and targets unrelated to the architecture, and the second is Arch/*/makefile, Seeing arch knows that it is related to a particular architecture, that it is contained in the root directory of makefile, that provides Kbuild with specific information about the architecture, and that it contains the makefile of the sub-directories arch/*/the following levels of the hierarchy The third is the dense hiding in the drivers/and other sub-directories below the makefile.

In the process of building the kernel, Kbuild is first executed from the root directory makefile, which obtains the architecture-independent variables and dependencies, and obtains the architecture-specific variables from the arch/*/makefile. Used to extend the variables provided by the root directory makefile. At this point, Kbuild already has all the variables and targets required to build the kernel, then make enters the subdirectories, passes some variables to the makefile in the subdirectory, makefile the source files according to the configuration information, and builds a list of files to compile.

Then, and then there is a long way, you compile the kernel to spend how long, it is how long, but when the answer to the previous question has surfaced, it is clear that the ARCH/I386/PCI below the makefile is in DRIVERS/PCI below the makefile front, In other words, Pci_access_init is in front of Acpi_pci_init.

With these unspoken rules in mind, when we study a subsystem, we can get the order of execution of the initialization function and use Han Feng's attitude of treating diary in depth analysis.

Linux kernel (13)-Subsystem initialization with PCI subsystem as an example