Добавление патчей в ядро: различия между версиями

Материал из ALT Linux Wiki
мНет описания правки
Строка 94: Строка 94:
Если пач трогет фалы KConfig стоит обновить конфиги.
Если пач трогет фалы 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 ==
== Критерии добавления пачей в ядро std ==

Версия от 13:07, 29 сентября 2008

Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.
42px-Wikitext-ru.svg.png
Эту статью следует викифицировать.

Введение

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

  • просто интересно.
  • есть функцианальность, которую хотелось добавить, а в наших ядрах её нет.
  • расшерение поддержки железа. Есть железяка, она не работает, но есть пач и возможность проверить.

Почему этого не стоит делать:

  • Задача сложная, если не очень нужно, не забивате себе голову.

Чего не стоит делать:

  • Плодить разные flavour. Лучше доавить к имеющимся в идеале в std-def.
  • Делать только для себя. Если вы дабавили пач, делающий что то полезное, стоит его выложить в сизиф. Оно может ещё кому-то пригодиться.

Что нам нужно:

  • знание 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