Добавление патчей в ядро: различия между версиями
Строка 29: | Строка 29: | ||
git branch -a | git branch -a | ||
Оправившись от шока, вызванного обилием бранчей, разберёмся зачем каждый из них нужен. | Оправившись от шока, вызванного обилием бранчей, разберёмся зачем каждый из них нужен. | ||
При ближайшем рассмотрении все бранчи можно разделить на | При ближайшем рассмотрении все бранчи можно разделить на | ||
* feat-* | * feat-* | ||
* fix-* | * fix-* | ||
* kernel-image* | * kernel-image* | ||
* kernel- | * kernel-source* | ||
* | * остальные | ||
Расскажем о них по порядку. | |||
====kernel-image*==== | |||
Основные бранчи - это бранчи kernel-image-*, именно из них собираются ядра. Эти бранчи соответствуют flavour'ам, например, пакет kernel-image-std-def собирается из одноименного бранча. Остальные - std-pae, std-ll, std-srv являются его производными и в данный момент нам не интересны. Для начала получим себе копию этого бранча | Основные бранчи - это бранчи kernel-image-*, именно из них собираются ядра. Эти бранчи соответствуют flavour'ам, например, пакет kernel-image-std-def собирается из одноименного бранча. Остальные - std-pae, std-ll, std-srv являются его производными и в данный момент нам не интересны. Для начала получим себе копию этого бранча | ||
git checkout -b kernel-image-std-def origin/kernel-image-std-def | git checkout -b kernel-image-std-def origin/kernel-image-std-def | ||
теперь, посмотрев в полученную директорию, мы увидим | |||
файлы <tt>kernel-image.spec</tt>, <tt>.gear/</tt>, <tt>modules.build</tt>, <tt>subflavours</tt> и исходники ядра. | |||
modules.build это список модулей для скриптов автоматической сборки модулей | Spec-файл и директория .gear/ выполняют обычную роль. | ||
subflavours это список | Файл <tt>modules.build</tt> - это список модулей для скриптов автоматической | ||
сборки модулей, туда добавляются все модули, которые надо пересобрать после обновления ядра. | |||
Файл <tt>subflavours</tt> - это список subflavour'ов, которые надо обновить при обновлении основного subflavour. Например, мы обновляем и тестируем <tt>std-def</tt>, а потом эти изменения специальным скриптом затаскиваются в остальные subflavour. | |||
kernel-source это специальный бранч из которого собирается пакет kernel-source-''версия''. Этот пакет всегда содержит исходники ванильного ядра, и используется для сборки всех ядер своей | ====kernel-source==== | ||
- это специальный бранч из которого собирается пакет <tt>kernel-source-''версия''</tt>. | |||
Этот пакет всегда содержит исходники ванильного ядра, и используется для сборки всех ядер | |||
своей версии. Важно, что в этом пакете содержится, например, 2.6.25, а не 2.6.25.17. | |||
Перед сборкой <tt>gear</tt> делает ''diff'' между тегами <tt>v2.6.''текущая верся ядра''</tt> (например, <tt>v2.6.25</tt>) | |||
и бранчем <tt>kernel-image-''flavour''</tt>. Этот ''diff'' кладется в SRPM, | |||
а при сборке вытягивается <tt>kernel-source-''версия''</tt> и на него накладывается | |||
этот ''diff''. Таким образом, kernel-source имеет смысл трогать, только если вы пытаетесь собрать новую версию ядра. | |||
fix и feat это бранчи с пачами. Они "растут" из ванильного ядра(можно базовой (типа v2.6.25) можно, самой свежей ванильной) и содержат пачи добавляющиее(feat) какую-то возможность или устраняющие какую нибудь ошибку(fix). Далее они имееют структуру {fix,feat}-''подсистема''-''суть''. Например: fix-fs-security - устраняет уязвимости где в файлвых системах или VFS. feat-drivers-net-atl1e - добавляет драйвер для сетевой карточки atl1e. | fix и feat это бранчи с пачами. Они "растут" из ванильного ядра(можно базовой (типа v2.6.25) можно, самой свежей ванильной) и содержат пачи добавляющиее(feat) какую-то возможность или устраняющие какую нибудь ошибку(fix). Далее они имееют структуру {fix,feat}-''подсистема''-''суть''. Например: fix-fs-security - устраняет уязвимости где в файлвых системах или VFS. feat-drivers-net-atl1e - добавляет драйвер для сетевой карточки atl1e. |
Версия от 17:04, 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-source*
- остальные
Расскажем о них по порядку.
kernel-image*
Основные бранчи - это бранчи kernel-image-*, именно из них собираются ядра. Эти бранчи соответствуют flavour'ам, например, пакет kernel-image-std-def собирается из одноименного бранча. Остальные - std-pae, std-ll, std-srv являются его производными и в данный момент нам не интересны. Для начала получим себе копию этого бранча
git checkout -b kernel-image-std-def origin/kernel-image-std-def
теперь, посмотрев в полученную директорию, мы увидим файлы kernel-image.spec, .gear/, modules.build, subflavours и исходники ядра. Spec-файл и директория .gear/ выполняют обычную роль. Файл modules.build - это список модулей для скриптов автоматической сборки модулей, туда добавляются все модули, которые надо пересобрать после обновления ядра. Файл subflavours - это список subflavour'ов, которые надо обновить при обновлении основного 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)
- Желательно быть отключаемым при загрузке или собираться модулем
и не должен:
- Менять работу базовых систем ядра
- Мешать другим пачам
- Что либо портить.