Сборка модулей ядра

Введение

Ядро Linux содержит в себе множество кода, поддерживающего ту или иную возможность или обрудование. Основная часть этого кода вкомпилино в ядро и загружается с ним, обычно это код поддерки процессоров, памяти и других базовых вещей, а код необходимый только части пользователей: драйверы устройств, поддержка файловых систем, и тд собрано в виде модулей. Модули могут подключаться к ядру по команде пользователя (modprobe',insmod) или автоматически при помощи udev, также модули могуть быть выгруженны либо самим ядром либо командой rmmod.

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

О модулях и названиях

Поскольку в репозитарии может быть множество ядер, модули собираются так: имеется пакет с исходными кодами модуля, и пакет с модулем собранным для конкретного ядра. Приэтом SRPM второго содержит только spec и пачи, а исходные коды получает по сборочным зависимостям. Таким образом у нас есть пакеты:(module - имя модуля, flavour - вариант ядра)

kernel-source-<module> который содержит только исходники.

kernel-modules-<module>-<flavour> модуль module собраный для ядра flavour(например kernel-modules-nvidia-std-def) Теперь о релизах пакетов с модулями: поле release заполяется так alt<module release>.<kernel version>.<kernel release> где-

module release - релиз собственно модуля, тоесть если мы обновили именно модуль, то это поле изменяется

kernel version - версия ядра в формате 65535 * major version + 256 * mid version + minor version, тоесть 2.6.25 = 132633. Не пугайтесь это число рассчитавает скрипт, описаный позже.

kernel release - номер релиза пакета с ядром.
Таким образом модуль с nvidia для ядра kernel-image-std-def-2.6.25-alt8 будет kernel-modules-nvidia-std-def-173.14.12-alt1.132633.8

Как собрать модуль локально

Данная фаза нужна в первую очередь для тестирования модуля, и вобщем то необязательна, но полезна для понимания процесса.

Что нам нужно

Кроме gcc, make и прочих стандарнтных сборочных вещей нам нужно kernel-headers-modules-<flavour>(ну и всё что от него зависит). Этот пакет содержит ту частьисходных кодов, заголовочных файлов, make-файлов и скриптов которые необходимы для сборки модулей.

Собственно сборка

Скачав и распоковав исходники модуля мы обнаруживаем, что просто make обычно не работает. Проблема в том что для сборки модуля необходима часть ядра, и эту самую часть make ищет по адресу /lib/modules/<currnet kernel version>/build, и не получает доступ туда, потому что собираем мы от пользователя, а собирать от рута это мовитон. Для этого открываем Makefile и ищем переменную, чтото вроде KSRC или KERNELSOURC обычно идёт в начале и содержит в значении /lib/modules. Далее запускаем сборку например make KSRC=/usr/src/linux-2.6.25-std-def. Обычно модуль после этого собирается.

Собраный модуль можно попробовать загрузить insmod или положить его в другим модулям ядра в /lib/modules/<kernelversion> и загрузить modprobe. Если модуль загрузился и работает можно переходить к следующей части.

Как собрать модуль правильно

Почему предидущий способ неправилен? Потому что недестрибутивен. Для нормальной сборки нам нужно:

знание git. Крайне желательно хотя бы начальное знание этой вещи.

умениние пользоваться gear

доступ на git.altlinux.org

достаточно терпения.

Сборка kernel-source-module

Для начала нам стоит собрать пакет с исходниками модуля, этот пакет прост, и фактически содержит в себе только упаковные исходники, а его сборка только в запаковке. Для примера лучше взять что нибудь несложное и готовое, например сделать так git clone git://git.altlinux.org/people/silicium/packages/kernel-source-heci.git

mkdir kernel-source-module
cd kernel-source-module
git init-db
распакавать исходники
git add .
git commit -a -m "version" (ну или вариации)
git branch -m upstream (чтобы потом докладывать)
git checkout -b master
cp ../kernel-source-heci/.gear* .
cp ../kernel-source-heci/*.spec
mv kernel-source-heci.spec kernel-source-module.spec

Редактируем по образу и подобию kernel-source-module.spec там надо обычно заменить имя модуля, версию, описание и чейнджлог, сам процесс сборки обычно можно не трогать.

git add .gear *.spec
git commit -a

Далее собираем пакет при помощи gear. В результате в пакете должен быть всего один файл /usr/src/kernel/sources/kernel-source-module.tar.bz2

Обратите внимание что некоторые пакеты с исходниками в своём имени содержат версию. например kernel-source-heci-5.0.0.31-5.0.0.31-alt1. сделано это для того чтобы можно иметь возможность собирать разные весии ядер с разными версиями модулей. Например новые модули не собираются с 2.6.18.

Сборка самого модуля

Про шаблоны

Поскольку править спеки каждого пакета с модулями для каждой версии ядра несколько глупо, была разработана схема при которой для каждого модуля создается шаблон, а специально обученный скрипт, подгоняет этот шаблон к конкретному ядру, и собирает пакет с модулем. Сами шаблоны храняться в git репозитории, в котором есть множество веток, ветки с шаблонами называются template/<module>/<distro> где module собтвенно название модуля(например nvidia) а distro это то под что мы собирам, обычно это sisyphus но поскольку для разных бранчей шаблоны приходиться менять, можно уcтановить поле distro в соответвующее значение. Обычно используется alt-linux-4.0 для branch/4.0 и alt-linux-4.1 для branch/4.1.

===Подготовка шаблона

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

git clone git://git.altlinux.org/people/silicium/packages/kernel-build-scripts.git

Сборка

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

Рекомендации по взаимодействию с мейнтейнирами ядер