Добавление патчей в ядро
Материал из ALT Linux Wiki
(→Введение) |
(→Разбираемся с бранчами) |
||
Строка 23: | Строка 23: | ||
== Разбираемся с бранчами == | == Разбираемся с бранчами == | ||
- | Для начала нам | + | Для начала нам нужен git репозитарий с ядром. |
- | для этого мы его клоним, например | + | для этого мы его клоним, например, |
git clone git://git.altlinux.org/people/silicium/packages/kernel-image-2.6.25.git | git clone git://git.altlinux.org/people/silicium/packages/kernel-image-2.6.25.git | ||
Теперь заходим в kernel-image-2.6.25 и видим ванильное ядро. Дело в том что git cкопировал только ветку master. Посмотреть остальные ветки можно командой | Теперь заходим в kernel-image-2.6.25 и видим ванильное ядро. Дело в том что git cкопировал только ветку master. Посмотреть остальные ветки можно командой |
Версия 13:27, 29 сентября 2008
Содержание |
Введение
Эта статья описывает то, как добавить пачи к нашим ядрам и вообще рассказывает о git репозитории с ядром. Для начала стоит понять зачем в это лезть. Цели могут быть разные:
- просто интересно.
- есть функциональность, которую хотелось добавить, а в наших ядрах её нет.
- расширение поддержки железа. Есть железяка, она не работает, но есть пач и возможность проверить.
Почему этого не стоит делать:
- Задача сложная, если не очень нужно, не забивайте себе голову.
Чего не стоит делать:
- Плодить разные flavour. Лучше добавить к имеющимся.
- Делать только для себя. Если вы добавили пач, делающий что то полезное, стоит его выложить в сизиф. Оно может ещё кому-то пригодиться.
Что нам нужно:
- знание git. Хотя бы начальные. Вся разработка ядра ведётся в git, и его здесь ни как не обойти.
- Знание сборочной системы gear
- Доступ к репозитарию.
- Достаточно мощная машина. Ядро может собираться долго(около получаса) в зависимости от железа, и в процессе сборки потребовать до 1Gb под временные файлы. Будьте готовы что этот процесс съест много ресурсов.
- Доступ к git.alt. git репозитарий с ядром может занимать до 300Mb будьте готовы хотя бы раз скачать его полностью.
Разбираемся с бранчами
Для начала нам нужен git репозитарий с ядром. для этого мы его клоним, например,
git clone git://git.altlinux.org/people/silicium/packages/kernel-image-2.6.25.git
Теперь заходим в kernel-image-2.6.25 и видим ванильное ядро. Дело в том что git cкопировал только ветку master. Посмотреть остальные ветки можно командой
git branch -a
И видим множетество веток. Оправившись от шока вызваный обилем бранчей, разберёмся зачем какой нужен.
При ближайшем рассмотрении все бранчи можно разделить на:
- feat-*
- fix-*
- kernel-image*
- kernel-sources*
- другие
Основные бранчи это бранчи kernel-image-*, именно из них и собирается ядра. Таких бранчий там несколько соответвенно flavourам например пакет kernel-image-std-def собирается из одноименного бранча. остальные std-pae std-ll std-srv являются его производными и в данный момент нам не интересны. Для начала получим себе копию этого бранча
git checkout kernel-image-std-def -b origin/kernel-image-std-def
типерь посмотрев в директорию, мы увидим spec, .gear, modules.build, subflavours и исходники ядра. spec и .gear выполняют ту-же функцианальность что и в любом другом пакете. modules.build это список модулей для скриптов автоматической сборки модулей. Туда добавляются все модули которые надо пересобрать после обновления ядра subflavours это список subflavours которые надо обновить при обновлении основного subflavour. тоесть например мы обновляем std-def, тестируем, а потом эти изменение специальным скриптом затаскиваются в остальные subflavour
kernel-source это специальный бранч из которого собирается пакет kernel-source-версия. Этот пакет всегда содержит исходники ванильного ядра, и используется для сборки всех ядер своей весии. Важно что в этом пакете содержатся например 2.6.25 а не 2.6.25.17. Gear перед сборкой делает diff между тегами v2.6.текущая верся ядра(например v2.6.25) и бранчем kernel-image-flavour. Этот diff кладёться в SRPM а при сборке вытягивается kernel-source-версия и на него накладывается этот diff. kernel-source имеет смысл трогать только если вы пытаетесь собрать новую версию ядра.
fix и feat это бранчи с пачами. Они "растут" из ванильного ядра(можно базовой (типа v2.6.25) можно, самой свежей ванильной) и содержат пачи добавляющиее(feat) какую-то возможность или устраняющие какую нибудь ошибку(fix). Далее они имееют структуру {fix,feat}-подсистема-суть. Например: fix-fs-security - устраняет уязвимости где в файлвых системах или VFS. feat-drivers-net-atl1e - добавляет драйвер для сетевой карточки atl1e.
В общем случае:
- в один бранч можно класть несколько пачей.
- Разные вещи лучше держать в отдельных бранчах
- Не стоит делать бранчи на основе kernel-image-std-def. Это потом вызывает массу проблем.
- Если есть какие то фиксы, небходимые для мерджа или испраляющие возникающю проблему их стоит класть этот бранч.
Про названия, примеры:
- добавить новую wifi карточку надо feat-drivers-net-wireless-карточка
- исправить проблему с поддержкой процссоров fix-arch-cpu-проц
Добавить примеров
Добавление пачей
Собственно последовательность необходимая для добавление пачей. Для начала выберем имя брача, и для удобства назвовём его $branch. $vversion - это текущая весия ванильного ядра.Создаём бранч:
git checkout -b $branch v$vversion
Например
git checkout -b feat-driver-net-atl1e v2.6.25
Теперь приложим пач. Его можно либо приложить и закомитить. Тоесть:
patch -p$n < $patch find -name "*.orig"|xargs rm -f git add . git commit -a
В git commit стоит написать описание, собтвенно что этот пач делает. Ещё можно воспользоваться командой git am.
Вышеописанное действие надо повторять, применив все необходимые пачи.
Далее пробуем добавить наши пачи в исходные коды ядра.
git checkout kernel-image-std-def git merge $branch
После второй команды у нас могут возникнуть конфликты. Если они возникли их можно исправлять следующим итерационным алгоритмом.
git status
Увидили конфликтные файлы, выбрали один
$EDITOR $file
Ищим там строки >>>> , ====, <<<< и исправляем. Затем делаем
git add $file
И повторяем с каждым файлом затем делаем
git commit -a
Собственно смерджили. Если пач трогет фалы KConfig стоит обновить конфиги.
Сборка и публикация
Собрать ядро можно также как и любой пакет при помощи gear, только помните что пакет большой, собирается он долго, и при этом активно потребляет место.
После сборки иногда имеет смысл собрать модули, об это можно почтитать здесь. Только собственно сборка просходит командой
./buildmodules --hasher --hsh-workdir=/home/silicium/hasher -k std-def
Тоесть имя модуля не указвается. И нужена ссылка kernel на git репозитарий с ядром. Посколько имя модуля не указано этот скрипт пойдёт в git репозитарий, найдет там бранч kernel-modules-std-def и в нём файл modules.build и собирёт все модули для этого ядра. Собрав ядро и модули, можно приступать к тестированию. После тестирования стоит выложить результат работы в git. для этого при помощи
ssh git.alt clone /people/silicium/packages/kernel-image-2.6.25
Потом идём в директорию с ядром и добавляем(для удобства) remote. git.alt отвечает нам $url
git remote add public ssh://git.alt/$url git push --all public
Собственно после этого ядро все наши изменения заливаются на git.alt
Критерии добавления пачей в ядро std
Хороший пач должен:
- Быть полезным
- Быть переносимым (хотябы работать на x86_64 и i586)
- Желательно быть отключаемым при загрузке или собираться модулем
и не должен:
- Менять работу базовых систем ядра
- Мешать другим пачам
- Что либо портить.