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

Модули ядра

Ядро 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> — версия ядра в формате (2^16) * major + (2^8) * mid + minor, то есть 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 обычно не работает. Эта проблема специфична для Sisyphus/ALT Linux и состоит в том, что для сборки модуля необходимы заголовки ядра, которые ищутся в каталоге /lib/modules/<currnet kernel version>/build, но не могут быть найдены там, потому что в ALT Linux и Sisyphus доступ пользователям в /lib/modules/ запрещён.

Для того, чтобы обойти эту проблему, нужно переопределить переменную (обычно KERNELSOURCE или KSRC) в Makefile. Далее запускаем сборку, например make KSRC=/usr/src/linux-2.6.25-std-def. Обычно модуль после этого собирается.

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

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

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

• знание git (крайне желательно хотя бы начальное знание!)
• умение пользоваться gear и hasher
• настроенный hasher
• доступ на git.alt (для публикации результатов)
• достаточно терпения

Шаблоны

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

Подготовка рабочей директории

Нам потребуются утилиты для сборки модулей из пакета kernel-build-tools:

# apt-get update && apt-get install kernel-build-tools

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

$ mkdir ~/build-modules && cd ~/build-modules
$ ln -s <репозиторий с ядром> kernel
$ ln -s <репозиторий с модулями> modules

При поиске репозиториев на git.alt нужно знать, что

• репозитории с модулями обычно называются kernel-modules
• репозитории с ядром обычно называются kernel-image
• старые репозитории с ядрами могут называться kernel-image-version

Примеры:

$ git clone git://git.altlinux.org/people/silicium/packages/kernel-modules.git
$ git clone git://git.altlinux.org/people/shrek/packages/kernel-image.git
$ git clone git://git.altlinux.org/people/aspsk/packages/kernel-image-2.6.18.git

Для использования бранчей с шаблонами придётся их завести локально, например:

$ git branch -r | grep 'template/.*/sisyphus$'
$ for m in subfs nvidia; do git checkout -b template/$m/sisyphus origin/template/$m/sisyphus; done

Сборка модуля из шаблона

Сборка модуля из шаблона происходит в рабочей директории. Для сборки модуля module под flavour std-def с помощью hasher можно использовать в ~/build-modules команду

$ buildmodules -k std-def module

или для использования tmpfs (предполагается, что смонтирована в достаточном количестве под /tmp, используется pam_mktemp и создан каталог $TMP/hasher):

 $ buildmodules -k std-def --hsh-workdir=$TMP/hasher module

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

$ buildmodules --target i586 --hsh-options='--apt-config ../i586/apt.conf' -k std-def module

где .../i586/apt.conf — соответствующий конфигурационный файл для apt.

Если не указывать список модулей, то для каждого указанного flavour будет предпринята попытка собрать все модули, указанные в файле modules.build из ядерного бранча kernel-image-flavour.

Если нужно только создать подписанные теги - есть опция --no-build. Если нужно собирать пакеты - можно это делать либо через --hasher (тогда подписей в пакетах в любом случае изначально не будет), либо через --rpmbuild (тогда можно, как и предлагается, подписывать пакеты не при сборке, а после завершения сборки всех пакетов отдельным вызовом rpm --resign).

Логи сборки складываются в out/logs/kernel-modules-module-flavour.log.

Подробнее про опции скрипта buildmodules (и других) можно прочитать в файле README.ru.koi8 из репозитория kernel-build-tools.

Сборка модулей на git.alt

При сборке пакета на git.alt необходимо указать пару (репозиторий, тэг). Для (полу)автоматического обновления модулей в Сизифе можно использовать скрипт updatemodules.

Для данного темплейта этот скрипт обновляет бранчи для указанных flavour. Например, команда

$ updatemodules -k ovz-rhel

обновит бранчи для модулей, указанных в файле kernel-image-ovz-rhel:modules.build, создаст для них подписанные тэги и положит их в файл out/taglist в рабочей директории (в примере выше это ~/build-modules).

Увага! При работе с этим скриптом крайне желательно настроить gpg-agent, так как обычно подписываются много (>10) пакетов.

После этого можно запушить полученные бранчи и тэги на git.alt.

$ cd modules && git push --all && git push --tags && cd -

и добавить список модулей к последнему task'у (где предположительно уже добавлен на сборку соответствующий kernel-image):

$ for tag in $(cat out/taglist); do ssh git.alt task add repo packages/kernel-modules.git $tag; done

Следует, однако, учитывать, что updatemodules не затирает файл out/taglist и вам нужно делать это вручную.

Некоторые моменты

Если в репозитории: kernel-image-std-def-3.0.4-alt0.M60P.1.i586.rpm

Тогда в имени пакета: kernel-modules-emlog-std-def-0.51-alt2.196612.0.M60P.1.i586.rpm 0.51 - версия драйвера alt2 - релиз модуля (увеличивается при пересборке модуля без пересборки ядра) 196612 - версия ядра (генерируется автоматом, в зависимости от ядра) 0.M60P.1 - релиз ядра (автоматом)

В релиз модуля запаковывается версия + релиз ядра. СТРАШНО? (Ву-ха-ха-ха)?

Пересобрать отдельно один модуль

Допустим нужно пересобрать в репозитарий некий модуль без пересборки ядра и всех модулей.

Ветка kernel-modules-rt3070-std-def/sisyphus -- должна быть вытянута последняя из http://git.altlinux.org/gears/

1. Обновляем ветку template/rt3070/sisyphus
2. updatemodules -k std-def=3.0.4-alt1 rt3070
   1. Обновит ветку kernel-modules-rt3070-std-def/sisyphus
   2. Создаст тег: kernel-modules-rt3070-std-def-2.5.0.2-alt2.196612.1

Внимание, тега kernel-modules-rt3070-std-def-2.5.0.2-alt2.196612.1 - не должно быть, или updatemodules завершиться с неудачей. Убедится можно с:

cd modules 
stanv@hpc3: modules/ > git tag | grep rt3070
kernel-modules-rt3070-std-def-2.5.0.2-alt1.132647.3
...

Инфо, где вводить команду updatemodules

> pwd
/home/stanv/usb/build-modules
> ll
out/
tmp/
modules -> /home/stanv/usb/kernel-modules/

Создавать ссылку на репозиторий ядра необходимости нету.

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

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

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).

Создание нового шаблона

После сборки пакета с искодными кодами модуля, нам нужно создать новую ветку в репозитории с модулями:

$ cd modules
$ git checkout -b template/module/sisyphus origin/template/heci/sisyphus
$ rm -f SOURCES/*
$ mv kernel-modules-heci.spec kernel-modules-module.spec

где module — название вашего модуля.

Теперь редактируем спек, меняем: имя, версию, описания, чейнджлог, возможно надо будет поправить опции для сборки. И коммитим:

$ git add *.spec && git commit -a

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

Выкладывание модулей ничем не отличается от выкладывания обычных пакетов.

Выкладываем исходники:

$ ssh git.alt init-db kernel-source-module
$ cd kernel-source-module
$ git remote add public git.alt:packages/kernel-source-module.git
$ git push --all public

Выкладываем собственно модуль:

$ ssh git.alt init-db kernel-modules
$ cd modules
$ git remote add public git.alt:packages/kernel-modules.git
$ git push --all public

Осталось собрать пакеты через git.alt.

Важное замечание: для того чтобы сборка прошла правильно, kernel-source-module должен быть собран до сборки kernel-modules-module.

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

Для нормальной совместной работы рекомендуется:

• Оповестить мейнтейнеров ядер (в списке рассылки devel-kernel), о том что есть ваш модуль,
• При обновлении модуля обновлять сборки под максимальное количество ядер,
• Настроить git remote на kernel-modules других мейнтейнеров,
• В спеках kernel-modules- поле Packager установить в Kernel Maintainers team.

Про symvers и модули зависящие от других модулей

Иногда бывает, что пакет с модулями, должен собираться под другой пакет с модулями. Так например просиходит с gspca и v4l. Для нормальной сборки нам нужно 2 вещи: во-первых, проставить правильно зависимости на headers (у v4l есть свои хедеры), во-вторых, нужно импортировать файл с symvers. В gscpca проблема решилась добавлением следующей строчки в %prep фазу пакета с модулем gspca:

cat /usr/src/linux-%kversion-%flavour-%krelease/kernel-modules-v4l.symvers > Module.symvers