Linux Device Drivers 3 / Драйверы устройств Линукс (третье издание): 2.4. Компиляция и загрузка

2.4. Компиляция и загрузка

ximen 21.10.10 в 14:09

Пример "Привет, мир" с которого начинается эта глава небольшая демонстрация построения модуля и загрузки его в систему. Конечно весь процесс на много больше чем вы сумели увидеть. Этот раздел предоставляет больше подробностей как авторы модулей включают исходный код в выполняемую подсистему в ядре.

hardorsoft 25.10.10 в 09:27

2.4.1. Компиляция модулей

ximen 21.10.10 в 14:09

Для начала, давайте немного посмотрим на то, как должны собираться модули. Процесс сборки модуля сильно отличается от сборки пользовательского приложения. Ядро -- это большая отдельная программа с детальными и явными требованиями как его части собираются вместе. Процесс сборки также отличается от того, что был принят в предыдущих версиях ядра. Новая система сборки проще в использовании, даёт более корректный результат, но сильно отличается того, что было раньше. Система сборки ядра сложна, и мы рассмотрим только небольшой кусочек её. Файлы, расположенные в каталоге Documentation/kbuild дерева исходных кодов ядра, обязательны для прочтения всем, кто хочет понять как всё происходит на самом деле.

ximen 25.10.10 в 08:53

Вот несколько предварительных требований которые необходимо выполнить прежде чем заниматься построением модулей. Первая обеспечьте достаточно современную версию компилятора, утилиты модулей и другие необходимые инструменты. Файл Documentation/Changes в директории документации ядра всегда содержит список необходимых версий инструментов, вы должны свериться с ним прежде чем двигаться дальше.

hardorsoft 25.10.10 в 10:22

Попытки собрать ядро (и его модули) с неправильными версиями инструментов, могут привести в конечном счете к сложным проблемам. Помните, что порой версия компилятора который слишком новый может быть просто проблемной также как и слишком старый компилятор, исходные коды ядра делают великое множество предположений о (необходимом) компиляторе и новые версии могут иногда ломать что-нибудь время от времени.

hardorsoft 25.10.10 в 10:22

Если у вас до сих пор нет под рукой дерева ядра или он еще не сконфигурирован и не собран сейчас самое время сделать это. Вы не сможете создать способный загрузится модуль для ядра 2.6 без этого дерева в вашей файловой системе. Это также полезно ( но не требуется) иметь при себе запущенное ядро для которого вы что-то собираете.

hardorsoft 25.10.10 в 11:08

Раз все настроено, создать файл вашего модуля очень просто. Фактически, для примера «Привет, мир» описанного выше в этой главе будет достаточно написать одну строчку:

hardorsoft 25.10.10 в 11:36

<code>
obj-m := hello.o
</code>

ximen 21.10.10 в 14:09

Читатели кто знаком с утилитой make, более ранних версий вероятно будут удивлены как этот makefile работает. Все же он не выглядит как традиционные makefile (майкфайлы). Ответ, конечно, прост — система сборки ядра изменилась. Назначение верхних штатов (?) (которые дают преимущества расширенного синтаксиса предоставленного утилитой GNU make) создается один модуль из объектного файла hello.o. В результате после сборки объектного файла у нас появляется модуль с названием hello.ko

hardorsoft 25.10.10 в 12:05

Если у вас есть модуль с названием module.ko, который сгенерирован из двух файлов (названных, скажем, file2.c и file3.c) правильная абракадабра будет такой:

hardorsoft 25.10.10 в 12:15

<code>
obj-m := module.o
module-objs := file2.o file3.o
</code>

ximen 21.10.10 в 14:09

Для make файла как тот что был показан выше должен быть вызван внутри контекста большей системой сборки ядра. Если дерево каталогов вашего ядра, скажем папка ~/kernel-2.6 требуемая команда сборки make (напечатанная в директории содержащей исходный код модуля и make файла)для вашего модуля будет выглядеть так:

hardorsoft 25.10.10 в 12:30

<code>
make -C ~/kernel-2.6 M=pwd modules
</code>

ximen 21.10.10 в 14:10

Эта команда начинается с замены директории которая предоставляется параметром -С (это директория исходников ядра). Где можно найти make файл высшего уровня ядра(?). Параметр М= означает что make-файл перемещается в директорию где находится исходный код модуля пред попыткой собрать конечный модуль. Эта цель, в запуске ссылается на список найденных модулей в переменной obj-m, которая в нашем примере установлена как module.o

hardorsoft 25.10.10 в 12:49

Каждый раз набирать предыдущую команду make может стать утомительным, поэтому разработчики ядра придумали нечто вроде диалекта makefile, который помогает облегчить жизнь тем, кто собирает модули вне дерева ядра. Хитрость заключается в том, чтобы написать свой makefile, примерно такой:

ximen 25.10.10 в 13:42

# Если KERNELRELEASE определен, мы должны вызывать
#эту переменую из системы сборки ядра и должны использовать ее (системы) язык.
ifneq ($(KERNELRELEASE),)
obj-m := hello.o

# Иначе, вызванная напрямую из командной
#строки переменая вызовет систему сборки ядра.;

else
KERNELDIR ?= /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)
default:
$(MAKE) -C $(KERNELDIR) M=$(PWD) modules
endif

hardorsoft 25.10.10 в 12:57

Давайте ещё раз посмотрим на расширенный синтаксис утилиты GNU make в действии. Этот makefile читается дважды в типичной сборке. Когда makefile вызывается из командной строки, помните что переменная KERNELRELEASE не определена. Локализация директории исходников ядра дает преимущество в том факте что символьная ссылка собранная в директории куда установлены модули указывает обратно в дерево сборки ядра. Если у вас не запущено ядро для которого вы собираете модуль, вы можете снабдить параметр KERNELRELEASE= в командной строке, устанавливать переменную окружения KERNELDIR или переписать строку которая устанавливает переменную KERNELDIR в makefile-e. Раз дерево исходных кодов ядра было найдена, makefile вызывается по умолчанию: цель с которой запускается вторая команда make (с параметрами в makefile как $(MAKE)) — вызвать систему сборки ядра, как описано раньше. Следовательно, makefile устанавливает obj-m и makefile-ы ядра берут аккуратно на самом деле строительство модуля.

hardorsoft 27.10.10 в 04:44

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

hardorsoft 27.10.10 в 04:45

2.4.2. Загрузка и выгрузка модулей

ximen 21.10.10 в 14:10

Следующий шаг после сборки ядра — загрузка его в ядро. Как мы уже говорили эту работу выполняет insmod. Программа загружает код модуля и данные в ядро, которые по очереди выполняют функцию подобно ld которая связывает любой неразрешенный символ в модуле в таблицу символов ядра. В отличии от linker, тем не менее ядро на изменяет файл модуля на диске, и даже копию в памяти. Insmod допускает номер параметра командной строки (подробности смотрите в manpage), и это может назначать значения параметров в вашем модуле до связи с ядром. Так если модуль правильно спроектирован он может быть сконфигурирован во время загрузки, возможность конфигурации во время загрузки дает пользователю больше гибкости чем конфигурация во время компиляции, которая все же иногда используется. Конфигурация во время загрузки описана в разделе 2.8 этой главы.

hardorsoft 27.10.10 в 10:26

Заинтересованные читатели возможно захотят посмотреть как ядро поддерживает ismod: оно полагается на системный вызов определенный в kernel/module.c. Функция sys_init_module распределяет память ядра которую занимает модуль (эта память распределяется vmalloc, смотрите Раздел 8.4 Главы 2); когда копируется текст модуля в область памяти, разрешения ядра передаются модулю через таблицу символов, и вызовы функции инициализации модуля запускают все(?).

hardorsoft 27.10.10 в 11:01

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

hardorsoft 27.10.10 в 11:01

Утилита modeprobe обладает быстрой связкой. Modprobe, как и insmode, загружает модуль в ядро. Различие в том что она смотрит на загружаемый модуль видит ли он упоминание любого символа который в настоящее время определен в ядре. Если хоть одна такая ссылка найдена modprobe смотрит другие модули в текущем поиске модуля путь который определяет соответствующие символы. Когда modprobe находит эти модули (которые необходимы для загружаемых модулей) он также загружает их в ядро. Если вы используете insmod в этой ситуации, командные ошибки вместе с «неразрешенными символами» отправляются в системный logfile.

hardorsoft 27.10.10 в 11:22

Прежде мы говорили о том что модули могут выгружаться из ядра с помощью утилиты rmmod. Помните что модуль удаляется со ошибкой если ядро полагает что модуль все ещё используется (на пример, если программа все ещё открывает файл для устройства экспортированного как модуль) или если ядро было сконфигурировано с запретом удаления модуля. Это возможно если ядро сконфигурировано с разрешением «принудительного» удаления модулей, даже когда они загружены работой. Если вы передаете указатель где вы принимаете во внимание использование этого параметра, тем не менее вещи как вероятно большой ошибки достаточно для того чтобы система, в лучшем случае, перегрузилась .

hardorsoft 28.10.10 в 07:50

Программа lsmod предоставляет список модулей которые в данный момент загружены в ядро. Кроме того, любой такой модуль использует определенный модуль, также поддерживается. Lsmod читает виртуальный файл /proc/modules. Информацию о загруженных в данный момент модулях также можно найти в виртуальной файловой системе sysfs в /sys/module

hardorsoft 28.10.10 в 07:50

2.4.3. Зависимости версий

hardorsoft 26.10.10 в 08:27

Ясно, что код модуля необходимо скомпилировать для каждой версии ядра с которой он будет связан. Каждый модуль определяет символ называемым __module_kernel_version, который равносилен определению номера версии текущего ядра. Этот символ расположен в файле .modinfo Выполнимое Связывание и Форматирование [Executable Linking
and Format (ELF)?] разделе, подробно поговорим об этом в Главе 11. Пожалуйста помните, что это объяснение относится только к версии ядра 2.2 и 2.4; Линукс 2.0 выполняет туже работу по другому.

hardorsoft 28.10.10 в 09:15

Ядро не просто допускают что полученные модули были собраны непосредственно подходящей версией ядра. Один из шагов процесса сборки это связывание вашего модуля непосредственно с файлом (который называется vermagic.o) в текущем каталоге дерева ядра, этот объект содержит приличное количество информации о ядре в котором был собран модуль, включая целевую версию ядра, версию компилятора и установки числовых значений важных конфигурационных переменных. При попытке загрузить модуль эта информация может быть проверенна на совместимость с запущенным ядром. Если что-то происходит не так, то модуль не загружается и вы увидите что-то похожее:

hardorsoft 28.10.10 в 09:16

<code>
# insmod hello.ko
Error inserting './hello.ko': -1 Invalid module format
</code>

ximen 25.10.10 в 08:55

Взгляд в файл системного лога (/var/log/messages или то, что его заменяет в вашей системе) покажет конкретную проблему отказа загрузки модуля.

ximen 25.10.10 в 08:58

Если вам необходимо откомпилировать модуль для определенной версии ядра, то вы должны использовать систему сборки и дерево исходных кодов соответствующей версии. Простое изменение переменной KERNELDIR в примере makefile показанный заранее ловкий пример(?).

hardorsoft 28.10.10 в 09:53

Интерфейс ядра часто меняется от версии к версии. Если вы пишите модуль который рассчитан работать с разными версиями ядра (особенно если он должен работать в основных выпусках), вы вероятно сделаете макрос и используете конструкцию #ifdef, для того чтобы собрать ядро должным образом. Это издательство книги имеет отношение только ко одной основной версии ядра, таким образом вы не часто увидите версию теста в наших примерах кода. Но время от времени такая необходимость будет возникать. В таком случае вы хотите сделать использование определений найденых в файле linux/version.h. Этот заголовочный файл автоматически содержится в файле linux/module.h, определение в следующем макросе:

hardorsoft 28.10.10 в 10:31

UTS_RELEASE

ximen 21.10.10 в 14:10

Этот макрос разворачивается в строку, описывающую версию этого дерева ядра, например, "2.6.10".

ximen 25.10.10 в 13:45

LINUX_VERSION_CODE

ximen 21.10.10 в 14:10

Этот макрос раскрывается в двоичное представление версии ядра, по одному байту на каждую часть номера версии. Например, код для 2.6.10 будет 132618 (т.е. 0x02060a).[2] Используя эту информацию, вы можете (почти) легко определить с какой версией ядра вы имеете дело.

ximen 25.10.10 в 13:47

[2] Это позволяет иметь до 256 промежуточных версий между стабильными версиями.

ximen 25.10.10 в 13:48

KERNEL_VERSION(major,minor,release)

ximen 21.10.10 в 14:10

Этот макрос используется для построения целочисленного кода версии из отдельных чисел, составляющих номер версии. Например, <code>KERNEL_VERSION(2,6,10)</code> разворачивается в 132618. Макрос очень полезен, если требуется сравнение текущей и известной заранее версии ядра.

ximen 26.10.10 в 11:07

Большинство зависимостей от версии ядра можно обойти с помощью условий препроцессора, используя KERNEL_VERSION и LINUX_VERSION_CODE. Однако, зависимости от версий не должны замусоривать код кучей #ifdef. Лучший способ борьбы с несовместимостями -- выделить всё необходимое в отдельный заголовочный файл. Общее правило в данном случае сводится к тому, что код, который явно зависит от версии или платформы должен быть спрятан за низкоуровневыми макросами или функциями. Тогда высокоуровневый код может просто вызывать эти функции не заботясь о низкоуровневых деталях. Код, написанный таким образом становится проще и лучше читается.

ximen 26.10.10 в 12:02

2.4.4. Платформенные зависимости

hardorsoft 26.10.10 в 08:28

Каждая компьютерная платформа имеет свои особенности, и дизайнеры ядра свободны использовать все эти особенности для достижения максимальной производительности в целевом объектном файле.

ximen 25.10.10 в 09:00

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

hardorsoft 28.10.10 в 10:52

Например, архитектура IA32 (x86) разделяется на несколько различных типов процессоров. Старый процессор 80386 всё ещё поддерживается (пока), хотя его набор инструкций по сегодняшним меркам весьма ограничен. Более современные процессоры в своей архитектуре имеют ряд новых возможностей, включающих более быстрые инструкции для входа в ядро, межпроцессорных блокировок, копирования данных и т.д. Более новые процессоры также могут, работая в нужном режиме, использовать 36-битные (или большие) физические адреса, что позволяет им адресовать более 4GB физической памяти. Другие семейства процессоров имеют аналогичные улучшения. Ядро, в зависимости от разных опций конфигурации, может быть собрано с использованием этих дополнительных возможностей.

ximen 25.10.10 в 14:08

Ясно, если модуль работает в данным ядром он должен быть собран и таким образом понимание конечного процессора влияет каким будет ядро. И снова, объектный файл vermagic.o вступает в работу. Когда модуль загружен ядро проверяет параметры конфигурации данного процессора для модуля и делает уверенно подходящий запуск ядра. Если модуль скомпилирован с другими параметрами, тогда он не загружается.

hardorsoft 28.10.10 в 11:08

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

hardorsoft 28.10.10 в 11:50