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

Материал из ALT Linux Wiki
м Добавление пачей в ядро» переименована в «Добавление патчей в ядро»: орфография)
(Add {{historical}})
 
(не показано 30 промежуточных версий 11 участников)
Строка 1: Строка 1:
{{stub}}
{{historical}}
{{attention|Настоящая инструкция устарела и описывает положение вещей примерно на 2009 год.}}
 
[[Категория:Devel]]
[[Категория:Sisyphus]]
[[Категория:Kernel]]
 
== Введение ==
== Введение ==
Эта статья описывает то, как добавить пачи к нашим ядрам и вообще разкавает о внутренней жизни git репозиторя с ядром.  
Эта статья описывает то, как добавить патчи к нашим ядрам и вообще рассказывает о git репозитории с ядром.  
Для начала стоит понять зачем в это лезть. Цели могут быть разные:
Для начала стоит понять зачем в это лезть. Цели могут быть разные:
# просто интересно.  
* просто интересно.  
# есть функцианальность, которую хотелось добавить, а в наших ядрах её нет.
* есть функциональность, которую хотелось добавить, а в наших ядрах её нет.
# расшерение поддержки железа.  Есть железяка, она не работает, но есть пач и возможность проверить.
* расширение поддержки железа.  Есть железяка, она не работает, но есть патч и возможность проверить.


Почему этого не стоит делать:
Почему этого не стоит делать:
# Задача сложная, если не очень нужно, не забивате себе голову.
* Задача сложная, если не очень нужно, не забивайте себе голову.


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


Что нам нужно:
Что нам нужно:
# знание [[git]]. Хотя бы начальные. Вся разработка ядра ведёться в git, и его здесь ни как не обойти.
* знание [[git]]. Хотя бы начальные. Вся разработка ядра ведётся в git, и его здесь никак не обойти.
# Знание сборочной системы [[gear]]
* Знание сборочной системы [[gear]]
# Доступ к репозитарию.
* Доступ к репозиторию.
# Достаточно мощьная машина. Ядро может собираться очень долго(около получаса) в зависимости от железа, и в процессе сборки потреблать до 1Gb под временные файлы. Будте готовы что этот процесс съест много ресурсов.  
* Достаточно мощная машина. Ядро может собираться долго(около получаса) в зависимости от железа, и в процессе сборки потребовать до 1Gb под временные файлы. Будьте готовы что этот процесс съест много ресурсов.  
# Доступ к git.alt. git репозитарий с ядром может занимать до 300Mb будьте готовы хотябы раз его скачать полностью
* Доступ к git.alt. git репозиторий с ядром может занимать до 300Mb будьте готовы хотя бы раз скачать его полностью.


== Разбираемся с бранчами ==
== Разбираемся с бранчами ==
Для начала нам нужны git репозитарий с ядром.
Для начала нам нужен 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. Посмотреть остальные ветки можно с помощью команды
  git branch -a
  git branch -a
И видим множетество веток. Оправившись от шока от их обилия, разберёмся зачем какая нужна.
Оправившись от шока, вызванного обилием бранчей, разберёмся зачем каждый из них нужен.
 
При ближайшем рассмотрении все бранчи можно разделить на
При ближайшем рассмотрении все ветки можно разделить на:
* feat-*
* feat-*
* fix-*
* fix-*
* kernel-image*
* kernel-image*
* kernel-sources*
* 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
теперь, посмотрев в полученную директорию, мы увидим
файлы <tt>kernel-image.spec</tt>, <tt>.gear/</tt>, <tt>modules.build</tt>, <tt>subflavours</tt> и исходники ядра.
Spec-файл и директория .gear/ выполняют обычную роль.
Файл <tt>modules.build</tt> - это список модулей для скриптов автоматической
сборки модулей, туда добавляются все модули, которые надо пересобрать после обновления ядра.
Файл <tt>subflavours</tt> - это список subflavour'ов, которые надо обновить при обновлении основного subflavour. Например, мы обновляем и тестируем <tt>std-def</tt>, а потом эти изменения специальным скриптом затаскиваются в остальные subflavour.
 
====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====
- это бранчи с патчами. Они "растут" из ванильного ядра (можно базовой, вроде <tt>v2.6.25</tt>,
можно самой свежей ванильной) и содержат патчи, добавляющие (feat) какую-то возможность или
устраняющие какую нибудь ошибку (fix).
 
Далее, их названия имеют структуру <tt>{fix,feat}-''подсистема''-''суть''</tt>.
Например, <tt>fix-fs-security</tt> устраняет уязвимости в файловых системах или VFS,
а <tt>feat-drivers-net-atl1e</tt> добавляет драйвер для сетевой карточки atl1e.
 
В общем случае:
* в один бранч можно класть несколько патчей.
* Разные вещи лучше держать в отдельных бранчах
* Не стоит делать бранчи на основе <tt>kernel-image-std-def</tt>. Это потом вызывает массу проблем.
* Если есть какие то фиксы, необходимые для мерджа или исправляющие возникающую проблему, то их стоит класть в этот бранч.
 
Про названия, примеры:
* добавить новую wifi карточку надо в бранч <tt>feat-drivers-net-wireless-''карточка''</tt>
* исправить проблему с поддержкой процессоров - в бранч <tt>fix-arch-cpu-''проц''</tt>
''Добавить примеров''
 
== Добавление патчей ==
Собственно последовательность необходимая для добавление патчей.
Для начала выберем имя брача, и для удобства назовём его $branch. $vversion - это текущая версия ванильного ядра. Создаём бранч:
git checkout -b $branch v$version
Например
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
Ищем там строки >>>> , ====,  <<<< и устраняем конфликты. Так же можно воспользоваться <tt>git mergetool</tt>.
 
Затем делаем 
git add $file
И повторяем с каждым файлом
затем делаем
git commit -a
Собственно смерджили.
Если патч трогает фалы KConfig стоит обновить конфиги.
 
== Сборка и публикация ==
Собрать ядро можно, также как и любой пакет, при помощи gear, только помните что пакет большой, собирается он долго, и при этом активно потребляет место.
 
{{attention|Если при сборке без видимых причин выходит с ошибкой добавление патча -- проверьте на всякий, не связано ли это с модификацией .gear/rules как _до_ того места, от которого делается патч между ванильным ядром и текущим деревом, так и уже _после_ соответствующих тегов}}
 
После сборки иногда имеет смысл собрать модули, об это можно почитать [[Сборка модулей ядра|здесь]]. Только собственно сборка происходит командой
./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)
* Желательно быть отключаемым при загрузке или собираться модулем
 
и не должен:
* Менять работу базовых систем ядра
* Мешать другим патчам
* Что либо портить.


основные бранчи это бранчи 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 и исходники ядра.


== Добавление пачей ==
{{Category navigation|title=Kernel|category=Kernel}}
== Сборка ==
== Критерии добавления пачей в ядро std ==

Текущая версия от 02:47, 2 ноября 2022

Small-pyramides.png
Архивная информация.
Описываемые в этой статье вещи больше не используются и оставлены только для обратной совместимости.


Внимание! Настоящая инструкция устарела и описывает положение вещей примерно на 2009 год.

Введение

Эта статья описывает то, как добавить патчи к нашим ядрам и вообще рассказывает о 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$version

Например

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 mergetool.

Затем делаем

git add $file

И повторяем с каждым файлом затем делаем

git commit -a

Собственно смерджили. Если патч трогает фалы KConfig стоит обновить конфиги.

Сборка и публикация

Собрать ядро можно, также как и любой пакет, при помощи gear, только помните что пакет большой, собирается он долго, и при этом активно потребляет место.

Внимание! Если при сборке без видимых причин выходит с ошибкой добавление патча -- проверьте на всякий, не связано ли это с модификацией .gear/rules как _до_ того места, от которого делается патч между ванильным ядром и текущим деревом, так и уже _после_ соответствующих тегов


После сборки иногда имеет смысл собрать модули, об это можно почитать здесь. Только собственно сборка происходит командой

./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)
  • Желательно быть отключаемым при загрузке или собираться модулем

и не должен:

  • Менять работу базовых систем ядра
  • Мешать другим патчам
  • Что либо портить.