8.1.2 Процесс конфигурирования

Хотя процесс настройки вызывается с помощью команды make, была определена отдельная грамматика конфигурации. Она  также различается в версиях 2.4 и 2.6. Обратите внимание, что эта грамматика проста и близка к разговорному английскому языку; так что понять её вам может помочь простой взгляд на конфигурационные файлы (Kconfig для ядра версии 2.6 и файлы Config.in для ядра версии 2.4). Этот раздел не вдаётся в подробности грамматики; скорее, он нацелен на используемые методы. (* В версиях 2.4 и 2.6 методы остались почти теми же.)

▪Каждый подраздел ядра определяет правила для конфигурации в отдельном файле. Например, конфигурация сети хранится в файле Config.in (для ядра версии 2.4) или Kconfig (для ядра версии 2.6) в каталоге исходных текстов ядра net/. Этот файл импортируется архитектурно-зависимым файлом конфигурации. Например, в версии 2.4 конфигурационный файл для архитектуры MIPS arch/mips/config-shared.in имеет строку для импорта правил конфигурации для исходного файла VFS (fs/config.in).

▪Элемент конфигурации хранится в виде пары имя=значение. Имя элемента конфигурации начинается с префикса CONFIG_. Остальная часть имени является именем компонента, определённым в файле конфигурации. Ниже приведены значения, которые может иметь переменная конфигурации:
– bool: переменная конфигурации может иметь значение y или n.
– tristate: здесь переменная может иметь значения y, n или m (для модуля).
– string: здесь может быть задана любая строка ASCII символов. Например, в случае, если вы должны передать адрес сервера NFS, с которого хотите смонтировать начальную корневую файловую систему, он может быть задан во время сборки с помощью переменной, которая содержит строковое значение.
– integer: переменной может быть присвоено любое десятичное число.
– hexadecimal: переменной может быть присвоено любое шестнадцатеричное число.

▪При определении переменной конфигурации может быть указано, должен ли пользователь получить запрос для присвоения значения этой переменной. Если нет, этой переменной присваивается значение по умолчанию.

▪При определении переменной могут быть созданы зависимости. Зависимости используются для определения видимости записи.

▪Каждая переменная конфигурации может иметь связанный с ней текст помощи. Он отображается во время конфигурации. В ядре версии 2.4 весь текст помощи хранится в одном файле Documentation/Configure.help; текст помощи, связанный с определённой переменной, хранится после имени переменной. Тем не менее, в ядре версии 2.6 он хранится в отдельных файлах Kconfig.

Теперь мы подошли к последней, но самой важной части. Это понимание того, как процесс конфигурации экспортирует список выбранных компонентов для остальной части kbuild. Для достижения этого создаётся файл .config, который содержит список выбранных компонентов в формате имя = значение. Файл .config хранится в основном каталоге ядра и включён в Makefile верхнего уровня. Поле значения компонента используется, чтобы оценить, является ли исходный файл кандидатом для сборки и узнать, должен ли быть собран компонент (как модуль или напрямую скомпонован с ядром). Для этого kbuild использует умный метод. Давайте предположим, что в каталоге drivers/net существует драйвер sample.c, который экспортируется в процесс конфигурации под именем CONFIG_SAMPLE. Во время настройки с помощью команды make config пользователю будет предложено:

Build sample network driver (CONFIG_SAMPLE) [y/N]?

Если выбрать y, то в файл .config будет добавлено CONFIG_SAMPLE=y. В drivers/net/Makefile будет строка

obj-$(CONFIG_SAMPLE)+= sample.o

Когда при рекурсии в подкаталоге drivers/net встретится этот Makefile, kbuild преобразует эту строку к виду

obj-y+= sample.o

Так произойдёт потому, что включённый файл .config определил CONFIG_SAMPLE=y. Сборка ядра имеет правило для сборки obj-y; следовательно, этот исходный файл выбран для сборки. Аналогичным образом, если эта переменная выбрана в качестве модуля, то во время сборки модулей эта строка будет выглядеть следующим образом:

obj-m+= sample.o

Снова правило сборки obj-m определяет kbuild. Исходный код ядра тоже должен быть осведомлён о списке выбранных компонентов. Например, в коде init/main.c ядра версии 2.4 есть следующие строки:

#ifdef CONFIG_PCI

  pci_init();

#endif

Если пользователь выбрал во время конфигурации PCI, должен быть определён макрос CONFIG_PCI. Для того, чтобы сделать это, kbuild преобразует пару имя=значение в макроопределение в файле include/linux/autoconf.h. Этот файл разбивается на набор файлов заголовков в каталоге include/config. Например, в приведенном выше примере был бы файл include/config/pci.h, имеющий строку:

#define CONFIG_PCI

Таким образом, механизм kbuild гарантирует, что исходные файлы тоже могут быть осведомлены о компонентах.