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

Предыдущая  Содержание  Следующая V*D*V

Хотя процесс настройки вызывается с помощью команды 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 гарантирует, что исходные файлы тоже могут быть осведомлены о компонентах.

 

Предыдущая  Содержание  Следующая