Alt linux свое ядро

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

Содержание

Модули ядра [ править ]

Ядро 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 . . , где

• — релиз собственно модуля, то есть, если мы обновили именно модуль, то это поле изменяется;
• — версия ядра в формате (2^16) * major + (2^8) * mid + minor, то есть 2.6.25=132633. Не пугайтесь, это число рассчитывает скрипт, описанный позже;
• — релиз пакета с ядром.

К примеру, модуль с 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- (и всё что от него зависит). Этот пакет содержит ту часть исходных кодов, заголовочных файлов, make-файлов и скриптов, которые необходимы для сборки модулей для данного ядра.

Сборка [ править ]

Скачав и распаковав исходники модуля, мы обнаружим что просто make обычно не работает. Эта проблема специфична для Sisyphus/ALT Linux и состоит в том, что для сборки модуля необходимы заголовки ядра, которые ищутся в каталоге /lib/modules/ /build , но не могут быть найдены там, потому что в ALT Linux и Sisyphus доступ пользователям в /lib/modules/ запрещён.

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

Собранный модуль можно попробовать загрузить с помощью insmod , или положить его к другим модулям ядра в /lib/modules/ и загрузить 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:

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

Сборка модуля из шаблона (с помощью gear-specsubst) [ править ]

Когда вы собираете локально в тестовых целях, удобно установить параметр gear.specsubst.kflavour с вашим ядром:

После этого модуль можно собрать с помощью команды:

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

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

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

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

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

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

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

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

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

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

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

Сборка модулей на git.alt [ править ]

После этого можно запушить полученные бранчи и тэги на git.alt.

и добавить список модулей к последнему task’у (где предположительно уже добавлен на сборку соответствующий kernel-image):

Следует, однако, учитывать, что 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

В релиз модуля запаковывается версия + релиз ядра. СТРАШНО?

Пересобрать отдельно один модуль [ править ]

Допустим нужно пересобрать в репозитарий некий модуль без пересборки ядра и всех модулей.

Ветка 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 [ править ]

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

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

Далее собираем пакет при помощи 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).

Создание нового шаблона [ править ]

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

где module — название вашего модуля.

Теперь редактируем спек, меняем: имя, версию, описания, чейнджлог, возможно надо будет поправить опции для сборки. И коммитим:

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

Как выложить свой модуль в репозиторий [ править ]

Выкладывание модулей ничем не отличается от выкладывания обычных пакетов.

Выкладываем собственно модуль:

Осталось собрать пакеты через 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:

Источник

Kernelnotes

Эта страница была перемещена с freesource.info. Эта страница наверняка требует чистки и улучшения — смело правьте разметку и ссылки. Просьба по окончанию убрать этот шаблон со страницы.

Эта статья протухла. Её нужно существенно доработать или удалить

Использование своего ядра с дистрибутивами ALT Linux не поддерживается как техподдержкой ООО «Альт Линукс», так и силами сообщества. Созданные в багтрекере ошибки, относящиеся к самосборным ядрам, вероятнее всего, будут закрыты как NOTABUG.

Эта страница не описывает, как собирать ядра с kernel.org, но как собирать ядра из репозиториев ALT Linux.

Содержание

Последняя информация о том, как правильно собирать ядро [ править ]

Последняя информация о том, как правильно собирать ядро, находится в пакете kernel-build-tools в файле README.ru.koi8; его посмотреть можно в git-репозитории пакета, например, тут (ссылка со временем устареет): README.ru.koi8

Зачем может быть нужно собирать своё ядро? [ править ]

• Вы разработчик ядра.
• Вам нужно ядро, собранное каким-то особым способом (например, со включенной экспериментальной опцией), и ядра в ALT Linux не собраны таким образом.
• Вы пытаетесь отладить проблему в ядре ALT Linux и в багтракере, списке рассылки или техподдержке вам подсказали, что для этого нужно собрать ядро специальным способом
• У вас есть устройство, не поддерживаемое ядрами ALT Linux (только изредка! Очень часто достаточно просто собрать свой модуль к ядру, см. ниже).

Почему обычно не нужно собирать своё ядро? [ править ]

• Это скучное занятие.
• Если вам нужен специальный драйвер, то достаточно собрать модуль к уже имеющемуся ядру.
• Распространённые мифы про сборку ядра ложны:
  • Сборка ядра — простое дело Современный PC — достаточно сложное устройство, и правильный выбор опций компиляции — нетривиальное занятие. Дистрибутивные ядра оптимизированы под «средний» компьютер, пересборка увеличивает производительность Не подтверждается тестами. Чаще наоборот: неправильно собранное ядро замедляет систему. Сборка ядра — обязательное дело любого линуксоида Нет© Ненужные драйвера тормозят и занимают память Ненужные драйвера лежат на диске в виде модулей и не загружаются в память. Ядро с драйверами, вкомпилированными внутрь, работает быстрее Не подтверждается тестами. Загрузка модулей занимает несколько секунд при старте компьютера, дальнейшее использование идентично по скорости вкомпилированным драйверам. (а для тех применений, где отсутствие лишнего просмотра таблицы действительно существенно — всяко требуется специалист, не судящий по глупым сказкам)

Предупреждение [ править ]

Статья частично протухла. vsu@ советует читать доки в kernel-build-tools .

Собираем новое ядро [ править ]

Будем для примера собирать ядро версии 2.6.23. Вам понадобится хорошая быстрая машина, с быстрым процессором, и большим объемом ОЗУ [1] . Для ускорения сборки можно использовать ccache, установив для этого переменные:

Подготовительный этап [ править ]

I [ править ]

У ALT Linux разработана своя среда (kernel-build-tools) для сборки ядер. Основным мантейнером этой среды является vsu; по состоянию на декабрь 2009 последние правки публиковал aspsk:

Как видно, среда состоит из набора скриптов.

II [ править ]

Репозиторий c ядром должен находиться в директории kernel.

Забираем ядро, например, у vsu или lakostis:

Добавляем репозиторий, содержащий новую версию ядра (для git-remote может потребоваться поставить пакет perl-GIT):

В master ветку этого репозитория Линус помещает обновления для ядер серии 2.6.23 (например 2.6.23.1, 2.6.23.2…). В нашем репозитории будет создана ветка linux-2.6.23/master, которая будет отслеживать обновления для ванильного ядра 2.6.23.

Загрузим с репозитория linux-2.6.23 исходный код ядра.

Теперь в нашем репозитории ветка linux-2.6.23/master содержит ядро 2.6.23 с обновлениями. Убедимся:

Собрираем пакет kernel-source-2.6.23-1.0.0-alt1.noarch.rpm [ править ]

Как видно, данный пакет не зависит от архитектуры. Внутри пакета содержиться только файл с иходными кодами ванильного ядра: /usr/src/kernel/sources/kernel-source-2.6.23.tar.bz2

Заметьте, что данный пакет содержит исходный код ядра версии 2.6.23, а не 2.6.23.1. Собрать этот пакет не составит труда. Достаточно:

В ответ на ругань add_changelog что версия пакета не изменилась, можно добавить к alt1 точку: ‘alt1.’, потом удалить. Версия пакета не изменяется, а изменяется имя пакета.

Осталось собрать сам пакет с помощью gear в hasher:

на результат не влияют, там BuildRequires(pre) не хватает. После сборки этот пакет будет находится в репозитории hasher-a.

Собираем пакет kernel-image-std-smp-2.6.23-alt1.i586.rpm [ править ]

Собственно этот пакет содержит само ядро + стандартные модули поставляемые с ядром.

Несколько слов о структуре репозитория. На мой взгляд следует различать ветки:

• kernel-source — цель этой ветки создать пакет с исходниками ванильного ядра 2.6.23 (мы использовали эту ветку на предыдущем шаге).
• начинающиеся с feat-*-* fix-*-* . Каждая такая ветка содержит ванильное ядро + какое-то одно исправление, дополнение, патч.

Имя ветки сообщает, какое конкретное дополнение она несет.

• fix-stable — содержит ванильное ядро с последними исправлениями 2.6.23.1.
• kernel-image-std-smp — содержит пропатчиное ядро. эту ветку мержутся ветки fix-stable, feat-*-*, fix-*-*, fix-stable

Цель ветки kernel-image-std-smp создать мега патч-бомбу который накладывается на ванильное ядро 2.6.23, скомпилировать бинарное ядро, собрать пакет.

Файл branches-to-merge используется скриптом merge-all-branches. Может возникнуть вопрос: «Зачем мержить ветки которые указаны в branches-to-merge, если они уже в замерженыы в ветку kernel-image-std-smp ?» Ответ: Периодически в этих ветках появляется что-то новое, вот скрипт и проверяет, что появилось. Ещё возможен вариант вида branch-* скрипт merge-all-branches проверяет, есть ли что-то новое, если нет — ничего не делает, если есть — спрашивает, надо ли это мержить.

В моем случае, накатывать 2.6.23 поверх пропатченого 2.6.18, бесмысленно, иначе там всё развалится. Придётся делать по сути rebase всех веток с патчами, и подцеплять к старой истории в самом конце. При сборке 2.6.23 лучше создать новые ветки fix-stable, kernel-image-std-smp, …

A [ править ]

Cоздадим ветку fix-stable. Задача этой ветки содержать последние официальные исправления для ядра от Linus Torvalds:

При будущих обновлениях можно поступать одним из следующим способов: 1. Из tracking branch:

2. Загрузить обновления непосредственно из репозитория Linus-а:

B [ править ]

Создадим ветку kernel-image-std-smp на основе тега v2.6.23. Задача этой ветки содержать код ядра со всеми приложеными патчами. То есть в эту ветку мержатся остальные ветки feat-*-* fix-*-*.

Заберем из старой ветки vsu/kernel-image-std-smp файлы: kernel-image.spec config-i586 config-x86_64 branches-to-merge .gear/rules modules.build

Для каждого вышеперечисленного файла выполним:

флаг -f указывает добавить .gear/rules, даже если он занесен в .gitignore

C [ править ]

Создадим ветки feat-*-* и fix-*-*. Например создадим ветку добавляющую поддержку файловой системы unioinfs.

Патч можно наложить в ручную (patch -p1 feat-core- -rt feat-core-bootsplash feat-evms feat-evms-nodm feat-fs-squashfs feat-fs-unionfs fix-core- -init fix-core- -syslog fix-stable kernel-image-std-smp kernel-source master

D [ править ]

Мержим все исправления в ветку kernel-image-std-smp, исправляем конфликты.

E [ править ]

В ветке kernel-image-std-smp, создадим новый конфиг на базе старого:

При обработке make oldconfig, следует учитывать тот факт, что при наличии возможности скомпилировать некую часть ядра в виде модуля, следует ее выбрать. Чаще всего модули не компилируются непосредственно в ядро, но бывают исключения.

Проверяем все ли впорядке:

Опцию CONFIG_LOCALVERSION_AUTO следует отключить.

F [ править ]

Сборка дополнительных модулей [ править ]

A [ править ]

Каждый пакет, несущий дополнительный модуль собирается на основе шаблона. Шаблоны для всех дополнительных модулей раньше можно было загрузить с CVS:

Теперь шаблоны для модулей находятся в репозиториях kernel-modules у мантейнеров.

B [ править ]

Например, при сборке пакета kernel-modules-nvidia-std-smp-100.14.19-alt3.132631.1.i586.rpm будет использован шаблон modules/nvidia/kernel-modules-nvidia.spec и пакет kernel-source-nvidia-1001419-100.14.19-alt39.i586.rpm.

Пакет kernel-source-nvidia-1001419-100.14.19-alt39.i586.rpm берем из Sisyphus.

Пакеты kernel-source-* собираются как обычно. У кого-то лежит в гите, у кого-то старым дедовским способом. Получается что мантейниры модулей предлагают только kernel-source-%modulename, а сам бинарный модуль собирает vsu. Пакеты с бинарными модулями нужно собирать с каждым обновлением ядра. Если kernel-source-modulename плохо собран, тогда vsu выполняет двойную работу, либо забивает на этот модуль.

Undeground [ править ]

то есть, rpm-build-kernel — для BuildRequires, kernel-build-tools — скрипты для использования мантейнерами

pull . сейчас можно менять на merge что лучше cherry-pick или pull ? это в древних версиях git merge не предназначался для вызова руками зависит от ситуации… если в ветке куча коммитов, которые в свежей версии уже есть, merge с большой вероятностью не пройдёт автоматически если это патчи, которые не вошли в новую версию, вероятно, лучше сделать merge а я сделал cherry 🙁 кстати, в подобном случае может иметь смысл сначала сделать merge новой версии в эту ветку хотя это зависит от того, что в дальнейшем предполагается делать с этими изменениями если нужно получить патчи для свежего апстрима, придётся делать rebase если это какие-то изменения, которые апстриму нафиг не нужны, может быть проще смержить свежую версию апстрима туда и разгрести конфликты кстати, в самом свежем git сделали поддержку revert и cherry-pick для merge… указывается, с каким родителем делать дифф, который потом откатывается или применяется A->B ы :(то есть cherry-pick может забирвать все коммиты, между A и B ? нет… это git rebase умеет только он портит исходный бранч а в чем тогда новая фишка ? cherry-pick и revert — это почти одно и то же, различаются тем, в какую сторону применяется патч патч генерируется между указанным коммитом и его родителем если это merge, нужно указать, какой из родительских коммитов нужно брать вот эту опцию и добавили то есть, если сделать cherry-pick для merge, получится один мегапатч со всеми изменениями вообще это полезно для revert

Источник