Добавление патчей в ядро

Материал из ALT Linux Wiki

(Различия между версиями)
Перейти к: навигация, поиск
(Разбираемся с брачами)
(Добавление патчей)
 
(31 промежуточная версия не показана)
Строка 1: Строка 1:
-
{{stub}}
+
[[Категория:Devel]]
 +
[[Категория:Sisyphus]]
 +
[[Категория:Kernel]]
 +
 
 +
''Эту статить надо слегка довести, и добавить ссылок''
== Введение ==
== Введение ==
-
Эта статья описывает то, как добавить пачи к нашим ядрам и вообще разкавает о внутренней жизни git репозиторя с ядром.  
+
Эта статья описывает то, как добавить патчи к нашим ядрам и вообще рассказывает о git репозитории с ядром.  
Для начала стоит понять зачем в это лезть. Цели могут быть разные:
Для начала стоит понять зачем в это лезть. Цели могут быть разные:
-
# просто интересно.  
+
* просто интересно.  
-
# есть функцианальность, которую хотелось добавить, а в наших ядрах её нет.
+
* есть функциональность, которую хотелось добавить, а в наших ядрах её нет.
-
# расшерение поддержки железа.  Есть железяка, она не работает, но есть пач и возможность проверить.
+
* расширение поддержки железа.  Есть железяка, она не работает, но есть патч и возможность проверить.
Почему этого не стоит делать:
Почему этого не стоит делать:
-
# Задача сложная, если не очень нужно, не забивате себе голову.
+
* Задача сложная, если не очень нужно, не забивайте себе голову.
Чего не стоит делать:
Чего не стоит делать:
-
# Плодить разные flavour. Лучше доавить к имеющимся в идеале в std-def.
+
* Плодить разные flavour. Лучше добавить к имеющимся.
-
# Делать только для себя. Если вы дабавили пач, делающий что то полезное, стоит его выложить в сизиф. Оно может ещё кому-то пригодиться.
+
* Делать только для себя. Если вы добавили патч, делающий что то полезное, стоит его выложить в сизиф. Оно может ещё кому-то пригодиться.
Что нам нужно:
Что нам нужно:
-
# знание [[git]]. Хотя бы начальные
+
* знание [[git]]. Хотя бы начальные. Вся разработка ядра ведётся в git, и его здесь никак не обойти.
-
# Знание сборочной системы [[gear]]
+
* Знание сборочной системы [[gear]]
-
# Доступ к репозитарию.
+
* Доступ к репозиторию.
-
# Достаточно мощьная машина. Ядро может собираться очень долго(около получаса) в зависимости от железа, и в процессе сборки потреблать до 1Gb под временные файлы. Будте готовы что этот процесс съест много ресурсов.  
+
* Достаточно мощная машина. Ядро может собираться долго(около получаса) в зависимости от железа, и в процессе сборки потребовать до 1Gb под временные файлы. Будьте готовы что этот процесс съест много ресурсов.  
-
# Доступ к git.alt. git репозитарий с ядром может занимать до 300Mb будьте готовы хотябы раз его скачать полностью
+
* Доступ к 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
 +
теперь, посмотрев в полученную директорию, мы увидим
 +
файлы <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, только помните что пакет большой, собирается он долго, и при этом активно потребляет место.
 +
 
 +
После сборки иногда имеет смысл собрать модули, об это можно почитать [[Сборка модулей ядра|здесь]]. Только собственно сборка происходит командой
 +
./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)
 +
* Желательно быть отключаемым при загрузке или собираться модулем
 +
 
 +
и не должен:
 +
* Менять работу базовых систем ядра
 +
* Мешать другим патчам
 +
* Что либо портить.
-
== Разбираемся с брачами ==
 
-
Для начала нам нужны git репозитарий с ядром.
 
-
== Добавление пачей ==
+
{{Category navigation|title=Kernel|category=Kernel}}
-
== Сборка ==
+
-
== Критерии добавления пачей в ядро std ==
+

Текущая версия на 20:13, 18 ноября 2014


Эту статить надо слегка довести, и добавить ссылок

Содержание

Введение

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

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

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

и не должен:

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


 
Личные инструменты