Редактирование: Сборка модулей ядра

==Модули ядра==

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

Модули могут подключаться к ядру по команде пользователя (<tt>modprobe</tt>,
<tt>insmod</tt>) или автоматически при помощи udev, и быть выгружены либо самим
ядром, либо командой <tt>rmmod</tt>.

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

== О модулях и названиях ==
Поскольку в репозитории может быть множество ядер, модули собираются особым способом:
имеется пакет с исходными кодами модуля, и пакеты с модулями, собранным для конкретного
ядра. При этом SRPM последних содержит только .spec и патчи, а исходные коды получает по
сборочным зависимостям. Таким образом, для модуля ''module'' и варианта ядра ''flavour''
у нас имеются пакеты с именами
* <tt>kernel-source-''module''</tt> — содержит только исходники
* <tt>kernel-modules-''module''-''flavour''</tt> — модуль ''module'', собранный для ядра ''flavour'' (например, <tt>kernel-modules-nvidia-std-def</tt>)

Поле <tt>release</tt> пакетов с модулями заполняется так: <tt>alt<module_release>.<kernel_version>.<kernel_release></tt>, где
* <tt><module_release></tt> — релиз собственно модуля, то есть, если мы обновили именно модуль, то это поле изменяется;
* <tt><kernel_version></tt> — версия ядра в формате <tt>(2^16) * major + (2^8) * mid + minor</tt>, то есть <tt>2.6.25=132633</tt>. Не пугайтесь, это число рассчитывает скрипт, описанный позже;
* <tt><kernel_release></tt> — релиз пакета с ядром.

К примеру, модуль с <tt>nvidia</tt> для ядра <tt>kernel-image-std-def-2.6.25-alt8</tt> будет называться <tt>kernel-modules-nvidia-std-def-173.14.12-alt1.132633.8</tt>.

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

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

=== Сборка ===
Скачав и распаковав исходники модуля, мы обнаружим что просто {{cmd|make}} обычно не работает. Эта проблема специфична для Sisyphus/ALT Linux и состоит в том, что для сборки модуля необходимы заголовки ядра, которые ищутся в каталоге {{path|/lib/modules/<current kernel version>/build}}, но не могут быть найдены там, потому что в ALT Linux и Sisyphus доступ пользователям в {{path|/lib/modules/}} [https://bugzilla.altlinux.org/show_bug.cgi?id=5969 запрещён].

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

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

== Как собрать модуль правильно ==
Почему предыдущий способ не является правильным? Потому что он недистрибутивен.
Для нормальной сборки нам нужны:
* знание [[git]] (крайне желательно хотя бы начальное знание!)
* умение пользоваться [[gear]] и [[hasher]]
* настроенный [[hasher]]
* доступ на [[git.alt]] (для публикации результатов)
* достаточно терпения

=== Шаблоны ===
Поскольку править спеки каждого пакета с модулями для каждой версии ядра несколько глупо,
была разработана схема, при которой для каждого модуля создается шаблон, а <tt>gear</tt>
(при помощи директивы <tt>specsubst</tt>, в которой указывается <tt>flavour</tt> ядра)
подгоняет этот шаблон к конкретному ядру (в том числе вычисляет релиз модуля).
Остальная работа ложится на макрос <tt>%setup_kernel_module</tt>, который вычисляет все
остальные параметры, нужные для сборки модуля: версию ядра, релиз ядра и релиз модуля.
Сами шаблоны хранятся в git-репозитории, в котором есть множество веток, ветки
с шаблонами называются <tt>template/''module''/''distro''</tt>, где ''module'' — это
собственно название модуля (например, <tt>nvidia</tt>) а ''distro'' — это то, подо что
мы собираем. Обычно это <tt>sisyphus</tt>, но, поскольку для разных бранчей шаблоны
приходиться менять, можно установить поле ''distro'' в соответствующее значение.
Обычно ''distro'' сейчас совпадает с именем бранча.

=== Подготовка рабочей директории ===
Нам потребуются утилита <tt>km-create-tag</tt> для сборки модулей из пакета <tt>kernel-build-tools</tt>:
 # apt-get update && apt-get install kernel-build-tools

Также вам понадобится git репозиторий с шаблонами модулей, например, [http://git.altlinux.org/people/boyarsh/packages/kernel-modules.git git://git.altlinux.org/people/boyarsh/packages/kernel-modules.git] -- или репозиторий с отдельно взятым шаблоном, например, [http://git.altlinux.org/gears/k/kernel-modules-ipt-so-std-def.git git://git.altlinux.org/gears/k/kernel-modules-ipt-so-std-def.git]

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

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

=== Сборка модуля из шаблона (с помощью gear-specsubst) ===
Когда вы собираете локально в тестовых целях, удобно установить параметр
gear.specsubst.kflavour с вашим ядром:
 $ git config --add gear.specsubst.kflavour std-def
После этого модуль можно собрать с помощью команды:
 $ gear --commit --hasher hsh

<div id="tags_old"></div>
=== Создание тегов для сборки на git.alt (схема с gear-specsubst) ===
Например, для создания тега для модуля nvidia, собираемого для ядра std-def для архитектур x86_64 и i586:

<source lang="Bash">cd modules && km-create-tag -k std-def nvidia -a 'x86_64 i586' </source>

Или, для создания тегов для всех модулей, можно сделать:
<source lang=bash>
 $ GET ftp://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/files/list/src.list | \
 sed -r -n 's/^kernel-modules-([^[:space:]]+)-std-def[[:space:]].*/\1/p' | \
 xargs -r km-create-tag -k std-def 
</source>

=== Сборка модулей на git.alt ===
После этого можно запушить полученные бранчи и тэги на [[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 и km-create-tag не затирают файл out/taglist и вам нужно делать
это вручную.

Если же вы обновляете ядро, но не собираетесь обновлять шаблоны модулей, можно сделать:

$ ssh git.alt task add [номер задания] kmodules std-def

это добавит в задание (где предположительно уже добавлен на сборку соответствующий kernel-image) все модули, собранные для ядра std-def.

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

* Если в репозитории: 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/

# Изменяем ветку template/rt3070/sisyphus, коммитим наши изменения
# km-create-tag -k std-def rt3070 
# проверяем сборку чем-нибудь вроде: gear -t $(git describe) --hasher -- hsh $TMP/

== Сборка нового модуля ==
=== Сборка kernel-source-module ===
Для начала нам стоит собрать пакет с исходниками модуля. Этот пакет прост, и фактически содержит в себе только упакованные исходники, а его сборка состоит только в запаковке. Для примера лучше взять что нибудь несложное и готовое, например, сделать так:
<code>
 git clone  git://git.altlinux.org/gears/k/kernel-source-kdbus.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-kdbus/.gear* .
 cp ../kernel-source-kdbus/*.spec
 mv kernel-source-kdbus.spec kernel-source-''module''.spec
</code>
Редактируем по образу и подобию <tt>kernel-source-''module''.spec</tt> — обычно там надо заменить имя модуля, версию, описание и changelog, а сам процесс сборки обычно можно не трогать.
<code>
 git add .gear *.spec
 git commit -a
</code>
Далее собираем пакет при помощи [[gear]]. В результате в пакете должен оказаться всего один файл, а именно <tt>/usr/src/kernel/sources/kernel-source-''module''.tar.bz2</tt>

Обратите внимание на то, что некоторые пакеты с исходниками в своём '''имени''' содержат '''версию''', например, <tt>kernel-source-kdbus-5.0.0.31-5.0.0.31-alt1</tt>. Это сделано для того, чтобы можно было иметь возможность собирать разные версии ядер с разными версиями модулей (например, новые модули не собираются с 2.6.18).

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

После сборки пакета с исходными кодами модуля, нам нужно создать новую ветку в репозитории с модулями:
 $ cd modules
 $ git checkout -b template/''module''/sisyphus origin/template/kdbus/sisyphus
 $ rm -f SOURCES/*
 $ mv kernel-modules-kdbus.spec kernel-modules-''module''.spec
где ''module'' — название вашего модуля.

Теперь редактируем спек, меняем: имя, версию, описания, чейнджлог, возможно надо будет поправить опции для сборки. И коммитим:
 $ git add *.spec && git commit -a

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

=== Как выложить свой модуль в репозиторий ===
Выкладывание модулей ничем не отличается от выкладывания обычных пакетов.

Выкладываем исходники:
 $ 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''.

== Рекомендации по взаимодействию с мейнтейнерами ядер ==
Для нормальной совместной работы рекомендуется:
* '''При обновлении модуля обновлять сборки под максимальное количество ядер'''
* Своевременно обновлять шаблоны в репозитории на git.alt
* Оповестить мейнтейнеров ядер (в списке рассылки [https://lists.altlinux.org/mailman/listinfo/devel-kernel devel-kernel]), о том что есть ваш модуль,
* Настроить git remote на kernel-modules других мейнтейнеров,
* В спеках <tt>kernel-modules-</tt> поле Packager установить в Kernel Maintainers team.

== Про symvers и модули зависящие от других модулей ==
Иногда бывает, что пакет с модулями, должен собираться под другой пакет с модулями. Так например просиходит с gspca и v4l. Для нормальной сборки нам нужно 2 вещи: во-первых, проставить правильно зависимости на headers (у v4l есть свои хедеры), во-вторых, нужно импортировать файл с symvers. В gscpca проблема решилась добавлением следующей строчки в %prep фазу пакета с модулем gspca:
<code>
 cat /usr/src/linux-%kversion-%flavour-%krelease/kernel-modules-v4l.symvers > Module.symvers
</code>


{{Category navigation|title=Kernel|category=Kernel|sortkey={{SUBPAGENAME}}}}

[[Категория:Packaging]]