Кажется, никто не заострял внимание на том, как скрипт компоновщика настроен для предоставления указателей функций, используемых для инициализации кода ядра, поэтому давайте попробуем посмотреть, как красиво ядро ​​Linux создает скрипт компоновщика для вызовов инициализации.

Потому что приведенные выше замечательные ответы показали, как код Linux C может создавать и управлять всеми вызовами инициализации таким образом, как определить функцию как вызов инициализации, глобальную переменную для доступа к определенным функциям и функции, которые фактически вызывают определенный вызов инициализации при инициализации. фаза, я не хочу возвращаться к ним снова.

Поэтому здесь мы хотели бы сосредоточиться на том, как определяется каждый элемент переменной глобального массива с именем initcall_levels[], что это означает, что содержится в памяти, на которую указывает каждый элемент массив initcall_levels и т.д.

Во-первых, давайте попробуем понять, где определяются переменные в репозитории ядра Linux. Когда вы посмотрите на файл init/main.c, вы обнаружите, что все элементы массива initcall_levels не были определены в файле main.c и откуда-то импортированы.

extern initcall_t __initcall_start[];
extern initcall_t __initcall0_start[];
extern initcall_t __initcall1_start[];
extern initcall_t __initcall2_start[];
extern initcall_t __initcall3_start[];
extern initcall_t __initcall4_start[];
extern initcall_t __initcall5_start[];
extern initcall_t __initcall6_start[];
extern initcall_t __initcall7_start[];
extern initcall_t __initcall_end[];

Однако вы можете обнаружить, что эти переменные не объявлены ни в одном исходном коде C репозитория Linux, тогда откуда берутся эти переменные? Из скрипта компоновщика!

Linux предоставляет множество вспомогательных функций, помогающих программистам создавать файл сценария компоновщика для конкретной архитектуры, и они определены в файле linux/include/asm-generic/vmlinux.lds.h, который также предоставляет вспомогательную функцию для вызовов инициализации.

#define __VMLINUX_SYMBOL(x) _##x
#define __VMLINUX_SYMBOL_STR(x) "_" #x
#else
#define __VMLINUX_SYMBOL(x) x
#define __VMLINUX_SYMBOL_STR(x) #x
#endif

/* Indirect, so macros are expanded before pasting. */
#define VMLINUX_SYMBOL(x) __VMLINUX_SYMBOL(x)

#define INIT_CALLS_LEVEL(level)                     \
        VMLINUX_SYMBOL(__initcall##level##_start) = .;      \
        KEEP(*(.initcall##level##.init))            \
        KEEP(*(.initcall##level##s.init))           \

#define INIT_CALLS                          \
        VMLINUX_SYMBOL(__initcall_start) = .;           \
        KEEP(*(.initcallearly.init))                \
        INIT_CALLS_LEVEL(0)                 \
        INIT_CALLS_LEVEL(1)                 \
        INIT_CALLS_LEVEL(2)                 \
        INIT_CALLS_LEVEL(3)                 \
        INIT_CALLS_LEVEL(4)                 \
        INIT_CALLS_LEVEL(5)                 \
        INIT_CALLS_LEVEL(rootfs)                \
        INIT_CALLS_LEVEL(6)                 \
        INIT_CALLS_LEVEL(7)                 \
        VMLINUX_SYMBOL(__initcall_end) = .;

Мы можем легко обнаружить, что для initcall определено несколько макросов. Наиболее важным макросом является INIT_CALLS, который выдает синтаксис скрипта компоновщика, определяющий символ скрипта компоновщика, доступ к которому можно получить в простом коде C и в разделе ввода.

В частности, каждый вызов макроса INIT_CALLS_LEVEL(x) определяет новый символ с именем __initcall##level_##start (reference ## операция конкатенации в CPP); этот символ генерируется с помощью VMLINUX_SYMBOL(__initcall##level##_start) = .;. Например, макрос INIT_CALLS_LEVEL(1) определяет символ скрипта компоновщика с именем __initcall1_start.

В результате символы от __initcall0_start до __initcall7_start определены в скрипте компоновщика, и на них можно ссылаться в коде C, объявляя их с помощью ключевого слова extern.

Кроме того, макрос INIT_CALLS_LEVEL определяет новые разделы с именами .initcallN.init, где N — от 0 до 7. Сгенерированный раздел содержит все функции, определенные с помощью предоставленного макроса, такого как __define_initcall, как указано в атрибуте раздела.

#define __define_initcall(fn, id) \
    static initcall_t __initcall_##fn##id __used \
    __attribute__((__section__(".initcall" #id ".init"))) = fn

Созданные символы и разделы должны быть корректно настроены скриптом компоновщика, чтобы располагаться в одном разделе, разделе .init.data. Для этого используется макрос INIT_DATA_SECTION; и мы можем обнаружить, что он вызывает макрос INIT_CALLS, который мы смотрели.

#define INIT_DATA_SECTION(initsetup_align)              \
    .init.data : AT(ADDR(.init.data) - LOAD_OFFSET) {       \
        INIT_DATA                       \
        INIT_SETUP(initsetup_align)             \
        INIT_CALLS                      \
        CON_INITCALL                        \
        SECURITY_INITCALL                   \
        INIT_RAM_FS                     \
    }

Поэтому, вызывая макрос INIT_CALLS, компоновщик Linux находит символы __initcall0_start в __initcall7_start и .initcall0.init в .initcall7.init. в разделе .init.data, которые расположены встык. Здесь обратите внимание, что каждый символ не содержит никаких данных, но используется для определения того, где начинается и заканчивается сгенерированный раздел.

Затем попробуем посмотреть, правильно ли скомпилированное ядро ​​Linux содержит сгенерированные символы, секции и функцию. После компиляции ядра Linux с помощью инструмента nm мы можем получить все символы, определенные в скомпилированном образе Linux, называемом vmlinux.

//ordering nm result numerical order 
$nm -n vmlinux > symbol 
$vi symbol


ffffffff828ab1c8 T __initcall0_start
ffffffff828ab1c8 t __initcall_ipc_ns_init0
ffffffff828ab1d0 t __initcall_init_mmap_min_addr0
ffffffff828ab1d8 t __initcall_evm_display_config0
ffffffff828ab1e0 t __initcall_init_cpufreq_transition_notifier_list0
ffffffff828ab1e8 t __initcall_jit_init0
ffffffff828ab1f0 t __initcall_net_ns_init0
ffffffff828ab1f8 T __initcall1_start
ffffffff828ab1f8 t __initcall_xen_pvh_gnttab_setup1
ffffffff828ab200 t __initcall_e820__register_nvs_regions1
ffffffff828ab208 t __initcall_cpufreq_register_tsc_scaling1
......
ffffffff828ab3a8 t __initcall___gnttab_init1s
ffffffff828ab3b0 T __initcall2_start
ffffffff828ab3b0 t __initcall_irq_sysfs_init2
ffffffff828ab3b8 t __initcall_audit_init2
ffffffff828ab3c0 t __initcall_bdi_class_init2

Как показано выше, между символами __initcall0_start и __initcall2_start расположены все функции, определенные с помощью макроса pure_initcall. Например, давайте посмотрим на функцию ipc_ns_init, определенную в файле ipc/shim.c.

static int __init ipc_ns_init(void)
{
    const int err = shm_init_ns(&init_ipc_ns);
    WARN(err, "ipc: sysv shm_init_ns failed: %d\n", err);
    return err;
}

pure_initcall(ipc_ns_init); 

Как показано выше, макрос pure_initcall используется для помещения функции ipc_ns_init в секцию .initcall0.init, расположенную по символу __initcall0_start. Поэтому, как показано в приведенном ниже коде, все функции в секциях .initcallN.init вызываются одна за другой последовательно.

for (fn = initcall_levels[level]; fn < initcall_levels[level+1]; fn++)
    do_one_initcall(*fn);