8.1.1 Как работает процедура сборки

Ниже описаны характерные черты процедуры kbuild для ядер версии 2.4 и 2.6.

▪За сборку образа ядра и модулей отвечает высокоуровневый Makefile в исходных текстах ядра. Это достигается рекурсивным спуском в подкаталоги дерева исходных текстов ядра. Список подкаталогов, в которые необходимо зайти, зависит от выбора компонентов, то есть от процедуры конфигурации ядра. Как именно это делается, объясняется позже.Makefile-ы, находящиеся в подкаталогах, наследуют правила сборки объектов; в версии 2.4 они делают это подключая файл правил под названием Rules.make, который должен быть явно включён в каждый Makefile, находящийся в подкаталоге. Однако, это требование было исключено в процедуре kbuild версии 2.6.

▪Каждая архитектура (вариант для какого-либо процессора) должна экспортировать список компонентов для выбора в процессе конфигурирования; это включает в себя:
– Выбор разновидности процессора. Например, если ваша архитектура определена как ARM, то вам будет предложено выбрать вариант ARM.
– Оборудование на плате.
– Конфигурацию зависимого от платы оборудования.
– Компоненты подсистем ядра, которые остаются более или менее одинаковыми для всех архитектур, например, сетевой стек.
Каждая архитектура поддерживает базу данных компонентов в виде файлов; он может быть найден в каталоге arch/$ARCH. В ядре версии 2.4 этот файл называется config.in, тогда как в ядре версии 2.6 этот файл называется Kconfig. Во время конфигурации ядра этот файл анализируется и пользователю предлагается для выбора список компонентов. Возможно, вам придётся добавить в этот файл конфигурацию, относящуюся к вашему оборудованию.

▪Каждая архитектура должна экспортировать архитектурно-зависимый Makefile; следующий список сборочной информации  является уникальным для каждой архитектуры.
– Флаги, которые должны быть переданы различным инструментам
– Подкаталоги, которые необходимо посетить для сборки ядра
– Шаги постобработки, выполняемые после того, как образ собран
Они поставляются в архитектурно-зависимом Makefile в подкаталоге arch/$(ARCH). Makefile верхнего уровня импортирует архитектурно-зависимый Makefile. Чтобы понять архитектурно-зависимые определения для сборки, рекомендуем читателю заглянуть в какой-нибудь архитектурно-зависимый файл в дереве исходных текстов ядра (например, arch/mips/Makefile).

Ниже приводятся некоторые основные различия между процедурами сборки ядра версий 2.4 и 2.6.

▪Механизм конфигурации и сборки версии 2.6 имеет другую основу. kbuild версии 2.6 гораздо проще. Например, в ядре версии 2.4 архитектурно-зависимый Makefile не следует никакому стандарту; так что он отличается для различных архитектур. Платформа версии 2.6 была исправлена, чтобы поддерживать однородность.

▪В версии 2.4 простой набор make привёл бы в конечном итоге к разным результатам, в зависимости от состояния процедуры сборки. Например, если пользователь не выполнил конфигурирование и ввёл make, kbuild бы вызвал make config, выдавая вопросы на терминал и приводя пользователя в замешательство. В версии 2.6, однако, это приведёт к ошибке с надлежащей помощью для инструктирования пользователя.

▪В версии 2.4 объектные файлы создаются в том же каталоге, где находятся и исходные файлы. Однако, версия 2.6 позволяет иметь разные деревья исходных текстов и выходных объектных файлов (включая вывод конфигурации); это делается командой make O=dir, где dir - дерево объектных файлов.

▪В версии 2.4 при выполнении make dep оказывается воздействие на исходные файлы (то есть изменяются их временные метки). Это вызывает проблемы с некоторыми системами управления исходным кодом. С другой стороны, в ядре версии 2.6 во время сборки ядра исходные файлы остаются нетронутыми. Это гарантирует, что вы можете иметь дерево исходных текстов, доступное только для чтения. Это экономит дисковое пространство, если несколько пользователей хотят совместно использовать одно дерево исходных текстов, но иметь свои отдельные деревья объектных файлов.