Why we need this:
It can speed up the calling of initcalls, especially useful for some embed
device.
Idea:
1. The initcall can indicate a executing sequence by using the a
macro(initcall_depend()) in case of causing dependence problem in
multi-threaded running. Multi dependences is also allowed.
2. Ensure the calling of initcalls in the same layer would be completed before
the next layers' calling.
Usage:
You can indicate that initcall A must be run after initcall B by calling the
macro in A's file:
initcall_depend(A, B);
Means initcall A must run after initcall B finish executing(A depends on B).
Take notice of that if you declare A depends on B and C, you must put these
together as (the sequences is not important):
initcall_depend(A, B);
initcall_depend(A, C);
The detail of method:
A new section called .initcall.depend was added to
arch/xxx/kernel/vmlinux.lds.S to indicate the dependence relationship. A
struct called initcall_depend_t stored the relationship between A and B, and
was stored in section .initcall.depend.
Because all the dependence of A are put together, and the sequences of
initcall_depend_t was decided in linker order as initcall itself did. When A
is going to run, we can check if A would depend on others by checking the
point indicate the current item in dependence table. If the field "call" of
initcall_depend_t point to A, we know that A is depend on something and get
the prev_addr of the struct to find what it depends on. The field "prev_addr"
point to somewhere in .initcall.init section to indicate the address(also the
order) of depended initcall, so it can be used to find out whether other
threads complete executing of the depended initcall. If the current point of
the thread executing is smaller than prev_addr(it means some thread not
completed executing, not only this thread), we'll wait, otherwise we can
continue to check next thread. If all the thread is ok, we will run the
initcall and go to the next ...
