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

Материал из ALT Linux Wiki

(Различия между версиями)
Перейти к: навигация, поиск
(→Как собрать модуль правильно)
(→Рекомендации по взаимодействию с мейнтейнерами ядер)
 
(129 промежуточных версий не показаны.)
Строка 1: Строка 1:
-
{{stub}}
+
==Модули ядра==
-
= Введение =
+
-
Ядро Linux содержит в себе множество кода, поддерживающего ту или иную возможность или обрудование. Основная часть этого кода вкомпилино в ядро и загружается с ним, обычно это код поддерки процессоров, памяти и других базовых вещей, а код необходимый только части пользователей: драйверы устройств, поддержка файловых систем, и тд собрано в виде модулей. Модули могут подключаться к ядру по команде пользователя (''modprobe',''insmod'') или автоматически при помощи udev, также модули могуть быть выгруженны либо самим ядром либо командой ''rmmod''.
+
-
Большенство модулей находиться в пакете ядра, иногда по техническим, административным, или юредическим причинам некоторые модули выносяться в отдельные пакеты, и соответвенно собиратются отдельно.
+
Ядро Linux содержит в себе множество кода, поддерживающее ту или иную
 +
возможность или оборудование. Основная часть этого кода (обычно это код
 +
поддержки процессоров, памяти и других базовых вещей) вкомпилирована в ядро
 +
и загружается с ним, а части кода, необходимые только части пользователей —
 +
драйверы устройств, поддержка файловых систем, и т.д. — собраны в виде модулей.
 +
 
 +
Модули могут подключаться к ядру по команде пользователя (<tt>modprobe</tt>,
 +
<tt>insmod</tt>) или автоматически при помощи udev, и быть выгружены либо самим
 +
ядром, либо командой <tt>rmmod</tt>.
 +
 
 +
Большинство модулей находится в пакете ядра, однако иногда по техническим,
 +
административным или юридическим причинам некоторые модули собираются отдельно.
== О модулях и названиях ==
== О модулях и названиях ==
-
Поскольку в репозитарии может быть множество ядер, модули собираются так: имеется пакет с исходными кодами модуля, и пакет с модулем собранным для конкретного ядра. Приэтом SRPM второго содержит только spec и пачи, а исходные коды получает по сборочным зависимостям.
+
Поскольку в репозитории может быть множество ядер, модули собираются особым способом:
-
Таким образом у нас есть пакеты:(module - имя модуля, flavour - вариант ядра)
+
имеется пакет с исходными кодами модуля, и пакеты с модулями, собранным для конкретного
-
<li>kernel-source-<module> который содержит только исходники.
+
ядра. При этом SRPM последних содержит только .spec и патчи, а исходные коды получает по
-
<li>kernel-modules-<module>-<flavour> модуль module собраный для ядра flavour(например kernel-modules-nvidia-std-def)
+
сборочным зависимостям. Таким образом, для модуля ''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>, где
-
поле release заполяется так alt<module release>.<kernel version>.<kernel release> где-
+
* <tt><module_release></tt> — релиз собственно модуля, то есть, если мы обновили именно модуль, то это поле изменяется;
-
<li> module release - релиз собственно модуля, тоесть если мы обновили именно модуль, то это поле изменяется
+
* <tt><kernel_version></tt> — версия ядра в формате <tt>(2^16) * major + (2^8) * mid + minor</tt>, то есть <tt>2.6.25=132633</tt>. Не пугайтесь, это число рассчитывает скрипт, описанный позже;
-
<li> kernel version - версия ядра в формате 65535 * major version + 256 * mid version + minor version, тоесть 2.6.25 = 132633. Не пугайтесь это число рассчитавает скрипт, описаный позже.
+
* <tt><kernel_release></tt> — релиз пакета с ядром.
-
<li> kernel release - номер релиза пакета с ядром.<br>
+
-
Таким образом модуль с nvidia для ядра kernel-image-std-def-2.6.25-alt8 будет kernel-modules-nvidia-std-def-173.14.12-alt1.132633.8
+
К примеру, модуль с <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 и прочих стандарнтных сборочных вещей нам нужно 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.
+
=== Что нам нужно ===
-
Если модуль загрузился и работает можно переходить к следующей части.
+
Кроме 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 запрещён].
-
<li> знание git. Крайне желательно хотя бы начальное знание этой вещи.
+
 
-
<li> умениние пользоваться gear
+
Для того, чтобы обойти эту проблему, нужно переопределить переменную (обычно {{term|KERNELSOURCE}} или {{term|KSRC}}) в {{path|Makefile}}. Далее запускаем сборку, например {{cmd|make KSRC{{=}}/usr/src/linux-2.6.25-std-def}}. Обычно модуль после этого собирается.
-
<li> доступ на git.altlinux.org
+
 
-
<li> достаточно терпения.<br>
+
Собранный модуль можно попробовать загрузить с помощью {{cmd|insmod}}, или положить его к другим модулям ядра в {{path|/lib/modules/<kernelversion>}} и загрузить {{cmd|modprobe}}. Если модуль загрузился и работает, то можно переходить к следующей части.
-
== Сборка kernel-source-module ==
+
 
-
Для начала нам стоит собрать пакет с исходниками модуля, этот пакет прост, и фактически содержит в себе только упаковные исходники, а его сборка только в запаковке. Для примера лучше взять что нибудь несложное и готовое, например сделать так
+
== Как собрать модуль правильно ==
 +
Почему предыдущий способ не является правильным? Потому что он недистрибутивен.
 +
Для нормальной сборки нам нужны:
 +
* знание [[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 репозиторий с шаблонами модулей, например git://git.altlinux.org/people/boyarsh/packages/kernel-modules.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:
 +
 
 +
<source lang="Bash">cd modules && km-create-tag -k std-def nvidia</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>
<code>
-
git clone  git://git.altlinux.org/people/silicium/packages/kernel-source-heci.git
+
git clone  git://git.altlinux.org/gears/k/kernel-source-kdbus.git
-
  mkdir kernel-source-module
+
  mkdir kernel-source-''module''
-
  cd kernel-source-module
+
  cd kernel-source-''module''
  git init-db
  git init-db
-
  распакавать исходники
+
  распаковать исходники
  git add .
  git add .
  git commit -a -m "version" (ну или вариации)
  git commit -a -m "version" (ну или вариации)
  git branch -m upstream (чтобы потом докладывать)
  git branch -m upstream (чтобы потом докладывать)
  git checkout -b master
  git checkout -b master
-
  cp ../kernel-source-heci/.gear* .
+
  cp ../kernel-source-kdbus/.gear* .
-
  cp ../kernel-source-heci/*.spec
+
  cp ../kernel-source-kdbus/*.spec
-
  mv kernel-source-heci.spec kernel-source-module.spec
+
  mv kernel-source-kdbus.spec kernel-source-''module''.spec
</code>
</code>
-
Редактируем по образу и подобию kernel-source-module.spec там надо обычно заменить имя модуля, версию, описание и чейнджлог, сам процесс сборки обычно можно не трогать.
+
Редактируем по образу и подобию <tt>kernel-source-''module''.spec</tt> — обычно там надо заменить имя модуля, версию, описание и changelog, а сам процесс сборки обычно можно не трогать.
<code>
<code>
  git add .gear *.spec
  git add .gear *.spec
  git commit -a
  git commit -a
</code>
</code>
-
Далее собираем пакет при помощи gear. В результате в пакете должен быть всего один файл /usr/src/kernel/sources/kernel-source-module.tar.bz2
+
Далее собираем пакет при помощи [[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>
 +
 
-
Обратите внимание что некоторые пакеты с исходниками в своём '''имени''' содержат '''версию'''. например kernel-source-heci-5.0.0.31-5.0.0.31-alt1. сделано это для того чтобы можно иметь возможность собирать разные весии ядер с разными версиями модулей. Например новые модули не собираются с 2.6.18.
+
{{Category navigation|title=Kernel|category=Kernel|sortkey={{SUBPAGENAME}}}}
-
== Сборка самого модуля ==
+
-
= Как выложить модуль в репозитарий =
+
[[Категория:Packaging]]
-
= Рекомендации по взаимодействию с мейнтейнирами ядер =
+

Текущая версия на 12:21, 21 июля 2016

Содержание

Модули ядра

Ядро 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/<current 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 (для публикации результатов)
  • достаточно терпения

Шаблоны

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

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

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

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

Также вам понадобится git репозиторий с шаблонами модулей, например git://git.altlinux.org/people/boyarsh/packages/kernel-modules.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

Создание тегов для сборки на git.alt (схема с gear-specsubst)

Например, для создания тега для модуля nvidia, собираемого для ядра std-def: 

cd modules && km-create-tag -k std-def nvidia

Или, для создания тегов для всех модулей, можно сделать: 

 $ 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

Сборка модулей на 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/

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

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

Сборка kernel-source-module

Для начала нам стоит собрать пакет с исходниками модуля. Этот пакет прост, и фактически содержит в себе только упакованные исходники, а его сборка состоит только в запаковке. Для примера лучше взять что нибудь несложное и готовое, например, сделать так: 

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

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

git add .gear *.spec
git commit -a

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

Обратите внимание на то, что некоторые пакеты с исходниками в своём имени содержат версию, например, kernel-source-kdbus-5.0.0.31-5.0.0.31-alt1. Это сделано для того, чтобы можно было иметь возможность собирать разные версии ядер с разными версиями модулей (например, новые модули не собираются с 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
  • Оповестить мейнтейнеров ядер (в списке рассылки 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


Kernel

Capabilities • Features/OwKernel • Kernel-image-std-def • Kernel/Source • Kernel/build for dummies • KernelBuild • Kernelnotes • Kernelnotes/mike • Kernels • Kernels/Flavours • Kernels/History • Kernels/PAE • Kernels/PackageDescription • SampleSpecs/kernelmodule • SampleSpecs/kernelsource • Добавление патчей в ядро • Обновление ядра • Сборка модулей ядра

 
 
Личные инструменты