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

Материал из ALT Linux Wiki
мНет описания правки
 
(не показано 45 промежуточных версий 12 участников)
Строка 1: Строка 1:
==Модули ядра==
== Модули ядра ==


Ядро Linux содержит в себе множество кода, поддерживающего ту или иную
Ядро Linux содержит в себе множество кода, поддерживающее ту или иную
возможность или оборудование. Основная часть этого кода (обычно это код
возможность или оборудование. Основная часть этого кода (обычно это код
поддержки процессоров, памяти и других базовых вещей) вкомпилирована в ядро
поддержки процессоров, памяти и других базовых вещей) вкомпилирована в ядро
Строка 25: Строка 25:
Поле <tt>release</tt> пакетов с модулями заполняется так: <tt>alt<module_release>.<kernel_version>.<kernel_release></tt>, где
Поле <tt>release</tt> пакетов с модулями заполняется так: <tt>alt<module_release>.<kernel_version>.<kernel_release></tt>, где
* <tt><module_release></tt> — релиз собственно модуля, то есть, если мы обновили именно модуль, то это поле изменяется;
* <tt><module_release></tt> — релиз собственно модуля, то есть, если мы обновили именно модуль, то это поле изменяется;
* <tt><kernel_version></tt> — версия ядра в формате <tt>65535*major + 256 * mid + minor</tt>, то есть <tt>2.6.25=132633</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><kernel_release></tt> — релиз пакета с ядром.


Строка 37: Строка 37:


=== Сборка ===
=== Сборка ===
Скачав и распаковав исходники модуля, мы обнаружим что просто {{cmd|make}} обычно не работает. Эта проблема специфична для Sisyphus/ALT Linux и состоит в том, что для сборки модуля необходимы заголовки ядра, которые ищутся в каталоге {{path|/lib/modules/<currnet kernel version>/build}}, но не могут быть найдены там, потому что в ALT Linux и Sisyphus доступ пользователям в {{path|/lib/modules/}} запрещён.
Скачав и распаковав исходники модуля, мы обнаружим что просто {{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}}. Обычно модуль после этого собирается.
Для того, чтобы обойти эту проблему, нужно переопределить переменную (обычно {{term|KERNELSOURCE}} или {{term|KSRC}}) в {{path|Makefile}}. Далее запускаем сборку, например {{cmd|make KSRC{{=}}/usr/src/linux-2.6.25-std-def}}. Обычно модуль после этого собирается.
Строка 44: Строка 44:


== Как собрать модуль правильно ==
== Как собрать модуль правильно ==
Почему предыдущий способ неправилен? Потому что недистрибутивен. Для нормальной сборки нам нужны:
Почему предыдущий способ не является правильным? Потому что он не дистрибутивен.
Для нормальной сборки нам нужны:
* знание [[git]] (крайне желательно хотя бы начальное знание!)
* знание [[git]] (крайне желательно хотя бы начальное знание!)
* умение пользоваться [[gear]] и [[hasher]]
* умение пользоваться [[gear]] и [[hasher]]
* настроенный hasher
* настроенный [[hasher]]
* доступ на [[git.alt]] (для публикации результатов)
* доступ на [[git.alt]] (для публикации результатов)
* достаточно терпения
* достаточно терпения
=== Сборка kernel-source-module ===
Для начала нам стоит собрать пакет с исходниками модуля. Этот пакет прост, и фактически содержит в себе только упакованные исходники, а его сборка состоит только в запаковке. Для примера лучше взять что нибудь несложное и готовое, например, сделать так:
<code>
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
</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-heci-5.0.0.31-5.0.0.31-alt1</tt>. Это сделано для того, чтобы можно было иметь возможность собирать разные версии ядер с разными версиями модулей (например, новые модули не собираются с 2.6.18).


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


=== Подготовка рабочей директории ===
=== Подготовка рабочей директории ===
Нам потребуются утилиты для сборки модулей из пакета <tt>kernel-build-tools</tt>:
Нам потребуются утилита <tt>km-create-tag</tt> для сборки модулей из пакета <tt>kernel-build-tools</tt>:
  # apt-get update && apt-get install 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 нужно знать, что
Также вам понадобится 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]
* репозитории с модулями обычно называется <tt>kernel-modules</tt>
 
* репозиторий с ядром обычно называется <tt>kernel-image</tt>
Для использования бранчей с шаблонами придётся их завести локально, например:
* более старые ядра могут называться <tt>kernel-image-''version''</tt>
 
$ 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>
=== Управление архитектурами, для которых собираются модули ===
Разные ветки ядер в разных репозиториях собираются для разного набора архитектур.
Аналогично, многие модули имеют ограничения, в силу которых могут быть собраны не для всех возможных архитектур.


Примеры:
Начиная с kernel-build-tools-0.112-alt1, в нём реализована следующая функциональность:
$ 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


=== Сборка модуля из шаблона ===
В файле <tt>.gear/km-karch</tt> может сохраняться информация о архитектурах, для которых должен собираться модуль. Вот пример такого файла для virtualbox:
Сборка модуля из шаблона происходит в рабочей директории. Для сборки модуля ''module''
под flavour std-def с помощью hasher можно использовать команду
$ buildmodules -k std-def ''module''
Если хочется собрать такой же модуль под другую архитектуру, например под i586,
то следует использовать команду
$ buildmodules --target i586 --hsh-options='--apt-conf .../i586/apt.conf' -k std-def ''module''
где <tt>.../i586/apt.conf</tt> — соответствующий конфигурационный файл для apt.


Если не указывать список модулей, то для каждого указанного ''flavour'' будет
<source lang="text">
предпринята попытка собрать все модули, указанные в файле <tt>modules.build</tt>
std-pae %ix86
из ядерного бранча <tt>kernel-image-''flavour''</tt>.
*      %ix86 x86_64
</source>


Логи сборки складываются в <tt>out/logs/kernel-modules-''module''-''flavour''.log</tt>.
Такой файл описывает, что для ядра std-pae модуль должен собираться только на архитектуре i586, а для других ядер — для i586 и x86_64.


Подробнее про опции скрипта buildmodules (и других) можно прочитать в файле [http://git.altlinux.org/people/aspsk/packages/kernel-build-tools.git?p=kernel-build-tools.git;a=blob;f=README.ru.koi8;hb=HEAD README.ru.koi8] из репозитория <tt>kernel-build-tools</tt>.
Эта информация учитывается скриптом km-create-tag, но может быть переопределена при помощи ключа -a этого скрипта (не рекомендуется, так как эта информация не сохранится для следующего запуска km-create-tag и модуль для каких-то архитектур может оказаться молча потерян).


=== Сборка модулей на git.alt ===
Для того, чтоб это работало, в спек файле должны быть строки:
При сборке пакета на [[git.alt]] необходимо указать пару (репозиторий, тэг).
 
Для (полу)автоматического обновления модулей в Сизифе можно использовать скрипт updatemodules.
<source lang="text">
%define karch @karch@
ExclusiveArch: %karch
</source>
 
А в .gear/rules файле строка:
<source lang="text">
specsubst: kflavour karch
</source>
 
=== Создание тегов для сборки на git.alt (схема с gear-specsubst) ===
Например, для создания тега для модуля nvidia, собираемого для ядра std-def
 
<source lang="Bash">cd modules && km-create-tag -k std-def nvidia </source>


Для данного темплейта этот скрипт обновляет бранчи для указанных flavour.
Или, для создания тегов для всех модулей, можно сделать:
Например, команда
<source lang="bash">
  $ updatemodules -k ovz-rhel
  $ GET ftp://ftp.altlinux.org/pub/distributions/ALTLinux/Sisyphus/files/list/src.list | \
обновит бранчи для модулей, указанных в файле kernel-image-ovz-rhel:modules.build,
sed -r -n 's/^kernel-modules-([^[:space:]]+)-std-def[[:space:]].*/\1/p' | \
создаст для них подписанные тэги и положит их в файл <tt>out/taglist</tt>
xargs -r km-create-tag -k std-def
в рабочей директории.
</source>


=== Сборка модулей на git.alt ===
После этого можно запушить полученные бранчи и тэги на [[git.alt]].
После этого можно запушить полученные бранчи и тэги на [[git.alt]].
  $ cd modules && git push --all && git push --tags && cd -
  $ cd modules && git push --all && git push --tags && cd -
и добавить список модулей к последнему task'у:
и добавить список модулей к последнему task'у (где предположительно уже добавлен на сборку соответствующий kernel-image):
  $ for tag in $(cat out/taglist); do ssh git.alt task add repo packages/kernel-modules.git $tag; done
  $ for tag in $(cat out/taglist); do ssh git.alt task add repo packages/kernel-modules.git $tag; done
Следует, однако, учитывать, что updatemodules не затирает файл out/taglist и вам нужно делать
Следует, однако, учитывать, что updatemodules и km-create-tag не затирают файл out/taglist и вам нужно делать
это вручную.
это вручную.


== dead ==
Если же вы обновляете ядро, но не собираетесь обновлять шаблоны модулей, можно сделать:
 
$ 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 ===
Для начала нам стоит собрать пакет с исходниками модуля. Этот пакет прост, и фактически содержит в себе только упакованные исходники, а его сборка состоит только в запаковке. Для примера лучше взять что нибудь несложное и готовое, например, сделать так:
 
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


После этого нам нужно создать новую ветку в репозитории с модулями:
Редактируем по образу и подобию <tt>kernel-source-''module''.spec</tt> — обычно там надо заменить имя модуля, версию, описание и changelog, а сам процесс сборки обычно можно не трогать.
<code>
cd modules
git checkout -b template/'''module'''/sisyphus origin/template/heci/sisyphus
rm -f SOURCES/*
mv kernel-modules-heci.spec kernel-modules-'''module'''.spec
</code>
, где '''module''' - название вашего модуля.


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


== Как выложить модуль в репозиторий ==
Далее собираем пакет при помощи [[gear]]. В результате в пакете должен оказаться всего один файл, а именно <tt>/usr/src/kernel/sources/kernel-source-''module''.tar.bz2</tt>
Для начала необходимо у себя в git создать репозиторий и залить <tt>kernel-source-''module''</tt>:
 
<code>
Обратите внимание на то, что некоторые пакеты с исходниками в своём '''имени''' содержат '''версию''', например, <tt>kernel-source-kdbus-5.0.0.31-5.0.0.31-alt1</tt>. Это сделано для того, чтобы можно было иметь возможность собирать разные версии ядер с разными версиями модулей (например, новые модули не собираются с 2.6.18).
  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
После сборки пакета с исходными кодами модуля, нам нужно создать новую ветку в репозитории с модулями:
</code>
$ cd modules
Потом - выложить <tt>kernel-modules</tt>
$ git checkout -b template/''module''/sisyphus origin/template/kdbus/sisyphus
<code>
$ rm -f SOURCES/*
  ssh git.alt clone /people/silicium/packages/kernel-modules
$ mv kernel-modules-kdbus.spec kernel-modules-''module''.spec
  cd kernel-build-scripts/modules
где ''module'' — название вашего модуля.
  git remote add public git.alt:packages/kernel-modules.git
 
  git push --all public
Теперь редактируем спек, меняем: имя, версию, описания, чейнджлог, возможно надо будет поправить опции для сборки. И коммитим:
</code>
$ 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]].
Осталось собрать пакеты через [[git.alt]].


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


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


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




Текущая версия от 12:38, 21 апреля 2022

Модули ядра

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

Управление архитектурами, для которых собираются модули

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

Начиная с kernel-build-tools-0.112-alt1, в нём реализована следующая функциональность:

В файле .gear/km-karch может сохраняться информация о архитектурах, для которых должен собираться модуль. Вот пример такого файла для virtualbox: 

std-pae %ix86
*       %ix86 x86_64

Такой файл описывает, что для ядра std-pae модуль должен собираться только на архитектуре i586, а для других ядер — для i586 и x86_64.

Эта информация учитывается скриптом km-create-tag, но может быть переопределена при помощи ключа -a этого скрипта (не рекомендуется, так как эта информация не сохранится для следующего запуска km-create-tag и модуль для каких-то архитектур может оказаться молча потерян).

Для того, чтоб это работало, в спек файле должны быть строки: 

%define karch @karch@
ExclusiveArch: %karch

А в .gear/rules файле строка: 

specsubst: kflavour karch

Создание тегов для сборки на 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