Сборка модулей ядра: различия между версиями

Материал из ALT Linux Wiki
м (→‎О модулях и названиях: Изменены константы на степенные)
м (→‎Сборка модуля из шаблона: Исправлен параметр для hasher: --apt-conf => --apt-config)
Строка 94: Строка 94:
Если хочется собрать такой же модуль под другую архитектуру, например под i586,
Если хочется собрать такой же модуль под другую архитектуру, например под i586,
то следует использовать команду
то следует использовать команду
  $ buildmodules --target i586 --hsh-options='--apt-conf .../i586/apt.conf' -k std-def ''module''
  $ buildmodules --target i586 --hsh-options='--apt-config ../i586/apt.conf' -k std-def ''module''
где <tt>.../i586/apt.conf</tt> — соответствующий конфигурационный файл для apt.
где <tt>.../i586/apt.conf</tt> — соответствующий конфигурационный файл для apt.



Версия от 13:19, 8 марта 2011

Модули ядра

Ядро 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-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