Сборка модулей ядра: различия между версиями
мНет описания правки |
|||
(не показано 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> | * <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/< | Скачав и распаковав исходники модуля, мы обнаружим что просто {{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]] (для публикации результатов) | ||
* достаточно терпения | * достаточно терпения | ||
=== Шаблоны === | === Шаблоны === | ||
Поскольку править спеки каждого пакета с модулями для каждой версии ядра несколько глупо, | Поскольку править спеки каждого пакета с модулями для каждой версии ядра несколько глупо, | ||
была разработана схема, при которой для каждого модуля создается шаблон, а | была разработана схема, при которой для каждого модуля создается шаблон, а <tt>gear</tt> | ||
подгоняет этот шаблон к конкретному ядру (в том числе вычисляет релиз модуля) и | (при помощи директивы <tt>specsubst</tt>, в которой указывается <tt>flavour</tt> ядра) | ||
подгоняет этот шаблон к конкретному ядру (в том числе вычисляет релиз модуля). | |||
с шаблонами называются <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'' в соответствующее значение. | ||
Обычно | Обычно ''distro'' сейчас совпадает с именем бранча. | ||
=== Подготовка рабочей директории === | === Подготовка рабочей директории === | ||
Нам потребуются | Нам потребуются утилита <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 | ||
Также вам понадобится 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> | |||
=== Управление архитектурами, для которых собираются модули === | |||
Разные ветки ядер в разных репозиториях собираются для разного набора архитектур. | |||
Аналогично, многие модули имеют ограничения, в силу которых могут быть собраны не для всех возможных архитектур. | |||
Начиная с kernel-build-tools-0.112-alt1, в нём реализована следующая функциональность: | |||
В файле <tt>.gear/km-karch</tt> может сохраняться информация о архитектурах, для которых должен собираться модуль. Вот пример такого файла для virtualbox: | |||
<source lang="text"> | |||
std-pae %ix86 | |||
* %ix86 x86_64 | |||
</source> | |||
Такой файл описывает, что для ядра std-pae модуль должен собираться только на архитектуре i586, а для других ядер — для i586 и x86_64. | |||
Эта информация учитывается скриптом km-create-tag, но может быть переопределена при помощи ключа -a этого скрипта (не рекомендуется, так как эта информация не сохранится для следующего запуска km-create-tag и модуль для каких-то архитектур может оказаться молча потерян). | |||
=== | Для того, чтоб это работало, в спек файле должны быть строки: | ||
<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> | |||
Или, для создания тегов для всех модулей, можно сделать: | |||
<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]]. | После этого можно запушить полученные бранчи и тэги на [[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 не | Следует, однако, учитывать, что 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 === | |||
Для начала нам стоит собрать пакет с исходниками модуля. Этот пакет прост, и фактически содержит в себе только упакованные исходники, а его сборка состоит только в запаковке. Для примера лучше взять что нибудь несложное и готовое, например, сделать так: | |||
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, а сам процесс сборки обычно можно не трогать. | |||
< | |||
</ | |||
, | |||
git add .gear *.spec | |||
git add *.spec | |||
git commit -a | git commit -a | ||
Далее собираем пакет при помощи [[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). | ||
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 | После сборки пакета с исходными кодами модуля, нам нужно создать новую ветку в репозитории с модулями: | ||
$ cd modules | |||
$ git checkout -b template/''module''/sisyphus origin/template/kdbus/sisyphus | |||
$ rm -f SOURCES/* | |||
ssh git.alt | $ mv kernel-modules-kdbus.spec kernel-modules-''module''.spec | ||
cd | где ''module'' — название вашего модуля. | ||
git remote add public git.alt:packages/kernel-modules.git | |||
git push --all public | Теперь редактируем спек, меняем: имя, версию, описания, чейнджлог, возможно надо будет поправить опции для сборки. И коммитим: | ||
$ 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: | ||
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 | ||
Текущая версия от 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/
- Изменяем ветку 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
Редактируем по образу и подобию 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