Архитектурно-независимый исходный код

Дополнительные инструменты и документация

Рис. 9.5. Is /usr/src/linux/arch

Мы начнем с рассмотрения структуры архитектурно-независимой части исходного кода для понимания его разделения. Далее мы представим вашему вниманию обзор архитектурно-независимой части исходного кода, за которым последует краткий обзор дополнительных файлов, не попадающих ни в одну из категорий.

9.2 Сборка исходников ядра

9.2.1. 1 Архитектурно-независимый код

Архитектурно-независимая часть исходного кода делится на 11 поддиректорий, кате-

горизирующихся по функциональности. В табл. 9.2 приведены эти поддиректории.

Таблица 9.2. Архитектурно-независимые поддиректории

Поддиректория

Описание

crypto

drivers

include

init

ipc

kernel

lib

net

sound

Хранит код для криптографического API и различных алгоритмов шифрования-дешифрования

Код для драйверов устройств

Код для VFS и всех поддерживаемых в Linux подсистем

Заголовочные файлы. Эта директория имеет несколько поддиректорий с префиксом asm. Эти директории хранят архитектурно-зависимые заголовочные файлы. Оставшиеся директории хранят архитектурно-независимые заголовочные файлы

Архитектурно-независимая часть кода загрузки и инициализации

Код для поддержки межпроцессорной коммуникации (IPC)

Код для специфического кода ядра

Код для вспомогательных функций

Код для менеджера памяти

Код для поддержки различных сетевых протоколов

Код для поддержки звуковой системы

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

fs/

Директория f s/ делится далее на исходные файлы С-поддержки VFS и поддиректории для каждой из поддерживаемых файловых систем. Как подробно описано в гл. 7 «Планировщик и синхронизация ядра»¹, VFS - это слой абстрагирования для различных типов файловых систем. Код, находящийся в каждой из поддиректорий, состоит из кода, связывающего устройство хранения и слой абстрагирования VFS.

^к Очевидно, имеется в виду гл. 6, «Файловые системы». Примеч. науч. ред.

Глава 9 • Сборка ядра Linux

in it/

Директория init / содержит весь необходимый код для инициализации системы. Во время выполнения этого кода инициализируются все подсистемы ядра и создаются процессы инициализации.

kernel/

Основная часть кода ядра находится в директории kernel/. Большинство подсистем ядра расположены здесь, но некоторые, такие, как файловая система и память, имеют собственные директории того же уровня, что и kernel/. Имена файлов обычно соответствуют содержащемуся в них коду.

mm/

Директория mm/ содержит код управления памятью. Мы рассматривали примеры этого кода в гл. 4, «Управление памятью».

Архитектурно-зависимый код

Архитектурно-зависимый код - это часть кода ядра, связанная с настоящим аппаратным обеспечением. При рассмотрении этой части кода необходимо помнить, что изначально Linux разрабатывался для х86. Для минимизации сложности портирования некоторые х86-специфиические термины отражаются в глобальных структурах ядра, а также в именах переменных. Если вы рассмотрите код РРС и увидите имена, связанные с режимом преобразования адресов, которые не существуют на РРС, не паникуйте.

Сравнив код arch/i3 8 б и arch/ppc, вы увидите три очень похожих файла- def-conf ig, Kconf ig и Makefile. Эти файлы связаны с инфраструктурой системы сборки ядра. Назначение этих трех файлов объясняется в подразд. 9.2.2, «Сборка образа ядра».

В таблице 9.3 приведен обзор файлов и директорий, показанных в списке arch/ppc. Как только вы доберетесь до структур Makefiles и Kconf ig, стоит рассмотреть каждый из файлов в соответствующих директориях, где находится их код.

Таблица 9.3. Список исходных кодов arch/ppc

Поддиректория Описание

4xx__io Исходный код для МРС4хх-специфической части ввода-вывода, т. е. для

последовательного порта IBM STB3xxx SICC

82 60_io Исходный код для настроек связи с МРС8260

8xx_io Исходный код для настроек связи с МРС8хх

amiga Исходный код для компьютеров Amiga на основе PowerPC

boot Исходный код связан с загрузкой РРС. Эта поддиректория также

содержит поддиректорию с именем images, в которую сохраняются откомпилированные загрузочные образы

Сборка исходников ядра 513

Таблица 9.3. Список исходных кодов arch/ppc (Окончание)

conf ig Файлы настройки для сборки специфических РРС-платформ и архитектур

kernel Исходный код для аппаратных зависимостей подсистем ядра

lib Исходный код для специфических файлов РРС

math-emu Исходный код для эмуляции математики РРС

mm Исходный код для специфической РРС-части менеджера памяти. (Гл. 6^а

описывает эту тему подробнее)

platforms Специфический код для платформы, на которой смонтированы чипы РРС

syslib Часть ядра исходного кода для обобщенных аппаратно-специфических

подсистем

хлюп Исходный код для РРС-специфического отладчика

^а Очевидно, имеется в виду гл. 4, «Управление памятью». Примеч. науч. ред.

Директории в arch/x86 хранят структуру, подобную той, которую можно увидеть в архитектурно-зависимой директории РРС. В табл. 9.4 перечислены все возможные поддиректории.

Таблица 9.4. Список исходных кодов в arch/x86

Поддиректория Описание

boot Исходный код, связанный с загрузкой х86 и процессом инсталляции

kernel Исходный код для аппаратных зависимостей подсистем ядра

lib Исходный код для х86-специфических файлов библиотек

mach-x Исходный код для разновидностей архитектуры х86

math-emu Исходный код для функций математической эмуляции х86

mm Исходный код для х86-специфической части менеджера памяти. (В гл. 6

он описывается подробно)

oprof ile Исходный код для инструмента профилирования ядра oprof ile

pci Драйверы PCI x86

power Исходный код для управления питанием х86

Вы можете удивиться, почему два архитектурно-специфических списка не слишком похожи. Причина в том, что разбиение этой функциональности для данной архитектуры

Глава 9 • Сборка ядра Linux

может не подходить для других архитектур. Например, на РРС драйверы PCI варьируются на различных платформах и подплатформах, усложняя структуру поддиректории PCI по сравнению с ее аналогом из х86.

9.2.1.3 Дополнительные файлы и директории

В корне исходных файлов присутствует несколько файлов, не относящихся к архитектурно-зависимому и архитектурно-независимому коду. Они перечислены в табл. 9.5.

Таблица 9.5. Дополнительные файлы

Файл/директория Описание

COPYING Лицензия GPL, под которой распространяется Linux

CREDITS Список разработчиков проекта Linux

MAINTAINERS Список поддержки и инструкций по отправке изменений в ядро

README Сведения о версии

REPORTING-BUGS Описание процедуры сообщения об ошибках

documentation/ Директория с документацией о различных аспектах ядра Linux и

исходного кода. Полезный, хотя и быстро стареющий источник информации

scripts/ Хранилище инструментов и сценариев, использующихся во время

процесса сборки ядра

Сборка образа ядра

Система сборки ядра, или kbuid, - это механизм, с помощью которого можно выбирать варианты настройки сборки ядра. Для ядра из ветки 2.6 они обновились. Новая версия, kbuid, быстрее предшественника и соответственно лучше документирована. Система kbuid жестко зависит от иерархической структуры исходного кода.

9.2.2.1 Инструмент конфигурирования ядра

Инструмент конфигурирования ядра автоматически генерирует файлы настройки ядра с именем. с on fig. Это первый шаг сборки ядра. Файл. conf ig находится в корне исходного кода; он содержит описание всех настроек ядра, которые можно задать с помощью инструмента настройки. Каждая настройка сборки ядра имеет имя и связанное с ним значение. Имя имеет форму GONFIG__< NAME>, где < NAME> - метка, связанная с настройкой. Это значение может хранить одно из трех значений: у, m или п; у означает «yes» и то, что настройка должна быть включена в ядро или при компиляции; m означает «module» и, что настройка должна компилироваться отдельно от исходных кодов ядра. Если

Сборка исходников ядра

настройка не выбрана (или ее значение установлено в п для «по»), то в файле. с on fig соответствующая GONFIG_< NAME> закомментирована, т. е. не установлена. Настроечный файл. conf ig организован в порядке использования настроек инструментом настройки ядра и прокомментирован для обозначения каждой из настроек. Давайте рассмотрим пример файла. conf ig.

.config

1 #

2 # Automatically generated make config: don't edit

3 #

4 CONFIG_X86=y

5 CONFIG_MMU=y

6 CONFIG_UID16=y

7 CONFIG_GENERIC_ISA_DMA=y 8

9 #

10 # Code maturity level options

11 #

12 CONFIG_EXPERIMENTAL=y

13 CONFIG_CLEAN_COMPILE=

14 CONFIG_STANDALONE=y

15 CONFIG_BROKEN_ON_SMP=y 16

17 #

18 # General setup

19 #

20 CONFIG_SWAP=y

21 CONFIG_SYSVIPC=y

22 #CONFIG_POSIX_MQUEUE is not set

23 CONFIG_BSD_PROCESS_ACCT=y

Этот. conf ig-файл означает, что опции в строках с 4 до 7 находятся на верхнем уровне, настройки из строк с 12 до 15 находятся в меню завершающих настроек кода, а настройки в строках с 20 по 23 находятся в меню общих настроек.

Рассмотрев меню с помощью инструментов конфигурирования, вы увидите, что первые несколько настроек относятся к корню вместе с настройками кода общего уровня и общими настройками. Два последних пункта подразделяются на другие подменю. Это можно увидеть в qconf, вызываемой на выполнение при вызове xconf ig. Меню инструментов настройки по умолчанию показывает настройки для х86. Для просмотра связанных с РРС настроек, показанных на рис. 9.6, вызов xconf ig нужно дополнить параметром ARCH=ppc.

Глава 9 • Сборка ядра Linux

пёёзЯННмйнй

Die Option Help

I Option

_nloe**___ Z" -7Z

: - BProcessor Type (NEW) '. i! -®6: оУ7>: »7Фе< /8260 (NEW) 1 M | |-04a< (NEW) - ' » I |! -044x(NEW)

' i l-OPOWER3(NEW), ; j-OPOWER4and970(GS)(NEW) ^l08mc(NEW)

jNa™T_

j-Code maturity level option» General setup ^LOConfigire standard kernel features (for small systems) (NEW) EMBEDDED

pdAluVec Support (NEW) • - DThermal Management Support (NEW)

-Platform options ■ Bus options

•- PCMCIA/CardBus support ■ Advanced setup Device Drivers

[■ •Generic Driver Options -Memory Technology Devices (MTD)

- DCPiJ Frequency scaling

-Parallel port support •Plug and Play support -Block devices

-ATA/ATAPI/MFM/RLL support -SCSI device support -Old CD-ROM drivers (not SCSI, not IDE) ■ Miiti-device support (RAID and LVM) •Fusion MPT device support •IEEE 1394 (Fin-Wire) support -ISO device support -Macintosh device drivers ■ Networking support J- CAmaleur Radio support (NEW)

- SlrDA (infrared) subsystem support | *- Infrared-port device drivers

- О Bluetooth subsystem support (NEW)

-DWorkaroinds for PPC601 bugs (NEW)

PPC601_SVNC_FK

Рис. 9.6. Снимок qconf

Файл. config, генерируемый инструментами настройки, читается Makefile при сборке ядра с помощью вызова make bzlmage. Корневой Makefile тоже получает информацию, собираемую аппаратно-специфическим Makefile, который находится в arch/< arch>. Это делается с помощью директивы include:

Makefile

434 include.config

../

450 include $(srctree)/arch/$(ARCH)/Makefile

В этой точке Makefile всегда определяет, для какой архитектуры выполняется компиляция. Корневой Makefile определяет архитектуру компиляции одним из трех способов:

1. С помощью параметра командной строки ARCH.

2. С помощью переменной окружения ARCH.

3. Автоматически, получая информацию от вызова uname на хосте, на котором он выполняется.

Сборка исходников ядра

Если ядро компилируется не для той архитектуры, на которой производится сборка, передается параметр CROSS_COMPILE, означающий префикс используемого кросскомпилятора. Альтернативно может быть изменен сам Makefile, и переменная получит свое значение. Например, если выполняется компиляция для процессора РРС на платформе х86, будут выполняться следующие команды:

lkp: -#make xconfig ARCH=ppc

lkp: -#make ARCH=ppc CROSS_COMPILE=ppc-linux-

Файл.config также генерирует include/linux/autoconf.h, в котором #de-fine определяет выбираемое значение CONFIG_< NAME> и #undef сигнализирует о том, что это значение сбрасывается.

Sub-Makefiles

Система сборки опирается на sub-Makefiles, находящиеся в каждой из поддиректорий. Каждый Makefile поддиректории (называемый sub-Makefile или kbuild Makefile) определяет правила сборки объектных файлов из исходных, находящихся в поддиректориях, и применяется только для этой директории. Вызов каждого Makefile делается рекурсивно с проходом по всем поддиректориям: init/, drivers/, sound/, net, /.libHusr/.

Перед выполнением рекурсивных вызовов kbuild нужно убедиться в присутствии нескольких вещей, включая обновленный при необходимости include/linux/version, h и настройки символических ссылок inxlude/asm, указывающих на архитектурно-специфические файлы для компилируемой архитектуры. Например, если компиляция выполняется для РРС, include /asm указывает на include/asm-ppc. Кроме этого, kbuild собирает include/linux/autoconf.h и include/linux/config. После этого kbuild начинает рекурсивный спуск вниз по дереву.

Если вы разработчик ядра, вы можете добавить отдельные подсистемы, разместив файлы в специальных поддиректориях и обновив Makefile для внесения ваших изменений. Если ваш код внедряется в уже существующий файл, вы можете завернуть в блок #ifdef (CONFIG_< NAME> ). Если это значение выбрано в файле. config, оно определяется с помощью #def ine в include/linux/autoconf.h и ваши изменения будут учтены при компиляции.

Строки sub-Makefile имеют специальный формат, которого следует придерживаться при задании настроек сборки объектного файла. Эти Makefile располагаются последовательно из-за того, что информация с именами компилятора и библиотек определяется в корневом Makefile и архитектурно-специфическом корневом Makefile, а правила определяются в scripts/Makefile; *s. sub-Makefile составляет три возможных списка:

Глава 9 • Сборка ядра Linux

• $(obj-y). Перечисляет объектные файлы, связываемые внутри bui 11- in. о и далее внутри vmlinux.

• $(obj-m). Перечисляет объектные файлы, собираемые как модули.

• $(lib-y). Перечисляет объектные файлы, собираемые в lib. а.

Другими словами, когда мы делаем вызов make bzlmage, kbuild, мы собираем объектные файлы в ob j -у и связываем их. Базовая строка в sub-Makefile имеет вид

obj-$(CONFIG_FOO) += foo.o

Если CONFIG_FOO установлен в у в файле. conf ig для чтения корня Makefile, эта строка становится эквивалентной obj-у += foo.o kbuild, собирающей этот объектный файл из соответствующих f о о. с и файлов f о о. S из директорий, определенных правилами в scripts/makefile.build. (Скоро мы рассмотрим их подробнее.) Если f оо. с и f оо. S не существуют, выводится замечание

make[l]: *** No rule to make target ^x< subdir> /foo.c', needed by ⁴< subdir> /build-in.o'. Stop.

Способ, которым kbuild углубляется в директории, определяется ob j -у или ob j -m. Вы можете добавить директорию для настройки ob j -у, означающей, что нужно углубиться в указанную директорию:

obj-$(CONFIG_FOO) += /foo

Если /foo не существует, выдается следующее замечание:

Make[2]: *** No rule to make target *< dir> /foo/Makefile'. Stop.

I CML2 |

Откуда программа настройки, которая помогает нам при выборе настроек ядра, получает информацию? Система kbuild зависит от CML2, являющегося предметно-ориентированным языком, разработанным для настройки ядра. CML2 задает базовые правила, в соответствии с которыми интерпретируются читаемые данные и генерируются config-файлы. Этот файл описывает синтаксис и семантику языка. Базовые правила CML2 читаются программами настройки и сохраняются в файлы defconfig и Kconfig. Файлы defconfig находятся в корне архитектурно-зависимых директорий, arch/*/. Файлы Kconfig находятся в других поддиректориях. Файлы Kconfig хранят информацию, связанную с настройками сборки, такими, как меню перечисления вариантов, сопроводительная информация, значение имени config и информация о том, встраивается файл или компилируется в отдельный модуль. Более подробную информацию о CML2 и файле Kconfig см. в Documentation/kbuild/kconfig-language.txt

Сборка исходников ядра

Давайте еще раз рассмотрим, что мы узнали о процессе kbuild. Первым шагом является вызов инструмента настройки с помощью make xconf ig и make xconf ig ARCH=ppc в зависимости от архитектуры, для которой производится сборка. Сделанный в программе выбор сохраняется в файле.config. Самый верхний Makefile читает. config и вызывает make bz Image для сборки образа ядра. Далее верхний Makefile выполняет следующие процедуры, постепенно спускаясь вниз по поддиректориям:

1. Обновляет include/linux/version.h.

2. Устанавливает символическую связь include /asm указывать на архитектурно-специфические файлы архитектуры, для которой производится компиляция.

3. Собирает include/linux/autoconf.h.

4. Собирает include/linux/conf ig.h.

Далее kbuild спускается по директориям, вызывая sub-Makefile и создавая объектные файлы внутри каждой.

Мы рассмотрели структуру sub-Makefile. Теперь мы обратимся к Makefile высокого уровня и посмотрим, как он используется для управления системой сборки.

Makefile ядра Linux

Makefile Linux достаточно сложен. Этот подраздел описывает внутреннюю связь между всеми Makefile в дереве исходников и объясняет подробности реализации make. Тем не менее, если вы хотите расширить свои знания о make, необходимые для понимания всех особенностей kbuild Makefile, это будет хорошим началом. Более подробную информацию о make можно найти на www.gnu.org/software/make/ make.html.

В дереве исходников виртуально каждая директория имеет свой Makefile. Как было сказано в предыдущем разделе, Makefiles в поддеревьях разделяются на отдельные категории исходного кода (или подсистемы ядра) достаточно предсказуемо и соответственно определяют целевые исходные файлы, добавляемые в список при их поиске во время сборки. Расположенные рядом другие 5 Makefile определяют правила и выполняют их. Сюда входят корневой Makefile, arch/$ (ARCH) /Makefile, scripts/ Makefile, build, scripts/Makefile, clean и scripts/Makefile. Рис. 9.7 демонстрирует связи между различными Makefile. Мы определяем связи с помощью «включения» и «выполнения». Когда мы указываем связь «включения», мы имеем в виду, что Makefile вбирает в себя информацию о правилах из файла, указанного include < f ilename>. Когда мы говорим о связи «выполнения», мы имеем в виду то, что оригинальный Makefile выполняет вызов make -f для второго Makefile.

Когда выполняем вызов make для корня дерева исходников, мы вызываем корневой Makefile. Корневой Makefile определяет переменные, экспортируемые в остальные

Глава 9 • Сборка ядра Linux

/usr/src/linux2.6/

Makefile

I scripts/

arch/< arch> /

fs/

Makefile

I_____________________________________________

Makefile.build

Makefile.clean

MakefileJib

— — — Включен в
----------- Выполняется из

Рис. 9.7. Связи Makefile

Makefile, и выполняет дальнейшие вызовы make для каждой поддиректории корня, передавая в них управление.

Вызовы компилятора и компоновщика определены в scripts/Makefile.build. Это значит, что, когда мы попадаем в поддиректорию и собираем объект с помощью вызова make, мы тем самым выполняем правила, определенные в Make file, build. Это делается с помощью сокращенного вызова $ (Q) $ (МАКЕ) $ (build) =< dir>. Это правило используется для make внутри каждой поддиректории. Переменная build-это сокращение для

Makefile

1157 build: = -f $(if $(KBUILD_SRC), $(srctree)/)scripts/

Makefile.build obj

Вызов $ (Q) $ (MAKE) $ (build) =< dir> превращается в

^w@ make -f /path/to/source/scripts/Makefile.build obj=fs".

Далее scripts/Makefile.build читает Makefile директории, которая была передана в качестве параметра (fs в нашем примере). Эта sub-Makefile определяет

Сборка исходников ядра

один из нескольких списков obj-y, obj-m, lib-y и др. Файл scripts/Makefile, build вместе с определениями из включаемого scripts /Makefile, lib компилирует исходные файлы в поддиректории и спускается в другие перечисленные поддиректории. Вызов происходит аналогичным образом.

Давайте посмотрим, как это работает на примере. Если в инструменте настройки мы спустимся в меню File Systems и выберем поддержку журналируемой файловой системы Ext3, в. conf ig-файле будет установлена настройка CONFIG_EXT3_FS. Отрывок из соответствующего f s Makefile приведен далее.

Makefile

49 obj-$(CONFIG_EXT3_FS) += ext3/

Когда в соответствии с этим правилом запускается make, он определяет ob j -у + = ext3, делая ext3/ одним из элементов obj-y.make и распознав, что это поддиректория вызывает $ (Q) $ (МАКЕ) $ (build) =ext3.

$(Q)

Переменная $(Q) представляет собой префикс вызова $(МАКЕ). В дереве ядра 2.6 и в его улучшенной инфраструктуре вы можете подавить многословный режим вывода make, который выводит команды перед тем, как их выполнять. Когда строка начинается с @, вывод (echo) подавляется:

Makefile

254 ifeq($(KBUILD_VERBOSE), l)

255 quiet =

256 Q =

257 else

258 quiet=quiet_

259 Q = @

260 endif

Как вы можете видеть из этих строк, Q устанавливается в @, если KBUILD_VERBOSE установлена в 0, что означает, что мы не хотим компилироваться в многословном режиме.

После завершения процесса сборки мы заканчиваем работу с образом ядра. Этот загрузочный образ ядра называется zImage или vmlinuz, из-за того что ядро упаковывается с помощью алгоритма zlib. Обычные соглашения Linux также определяют местонахождение загрузочного образа в файловой системе; образ должен находиться в /boot или /. Теперь образ ядра готов для загрузки в память и загрузки системы.

Глава 9 • Сборка ядра Linux

Резюме

В этой главе рассмотрен процесс компиляции и компоновки структуры объектного файла, дающий возможность понять, что происходит с кодом и как он может быть исполнен. Также мы рассмотрели инфраструктуру, касающуюся системы сборки ядра, и то, как с этой системой сборки связана сама структура исходного кода. Мы бросили беглый взгляд на разделение исходного кода по функциональности в соответствии с подсистемами, которые мы рассматривали в предыдущих главах.

Упражнения

1. Опишите различные типы ELF-файлов и для чего они используются.

2. Какое место занимают разделы в объектном файле?

3. Рассмотрите arch/ppc /Kconfig и arch/i3 86 /Kconfig и определите, какие процессоры поддерживаются в каждой архитектуре.

4. Рассмотрите arch/ppc и arch/i38б и определите, какие у них общие файлы и директории. Изучите список их поддержки. Насколько они похожи?

5. Если вы кросскомпилируете ядро, какой параметр вам нужно задать в виде префикса кросскомпилятора?

6. В каком случае нужно задавать архитектуру через параметр ARCH?

7. Что такое sub-makefile? Как она работает?

8. Ознакомьтесь с scripts /Makefile, build, scripts/Makefile, clean и scripts/Makefile. lib. Перечислите, что они делают.

Глава

⇐ Предыдущая 45 46 47 48 495051 52 53 54 Следующая ⇒