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

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

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

Внимание! Настоящая инструкция устарела и описывает положение вещей примерно на 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)
Желательно быть отключаемым при загрузке или собираться модулем

и не должен:

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

Kernel

Kernel • Kernel/hardware errors • Capabilities • Features/OwKernel • Kernel/flavour • Kernel/History • Kernel/build for dummies • Kernel/Source • KernelBuild • SampleSpecs/kernelmodule • Kernelnotes • Kernelnotes/mike • SampleSpecs/kernelsource • Kernel/PackageDescription • Kernel/PAE • Realtime • Kernel/Testing • Userns restrict • Даунгрейд ядра • Добавление патчей в ядро • Обновление ядра • Сборка модулей ядра

@@ Строка 1: / Строка 1: @@
-{{stub}}
+{{historical}}
-{{Викифицировать}}
+{{attention|Настоящая инструкция устарела и описывает положение вещей примерно на 2009 год.}}
+[[Категория:Devel]]
+[[Категория:Sisyphus]]
+[[Категория:Kernel]]
 == Введение ==
-Эта статья описывает то, как добавить пачи к нашим ядрам и вообще рассказывает о git репозитории с ядром.
+Эта статья описывает то, как добавить патчи к нашим ядрам и вообще рассказывает о git репозитории с ядром.
 Для начала стоит понять зачем в это лезть. Цели могут быть разные:
 * просто интересно.
-* есть функцианальность, которую хотелось добавить, а в наших ядрах её нет.
+* есть функциональность, которую хотелось добавить, а в наших ядрах её нет.
-* расшерение поддержки железа.  Есть железяка, она не работает, но есть пач и возможность проверить.
+* расширение поддержки железа.  Есть железяка, она не работает, но есть патч и возможность проверить.
 Почему этого не стоит делать:
@@ Строка 13: / Строка 18: @@
 Чего не стоит делать:
 * Плодить разные flavour. Лучше добавить к имеющимся.
-* Делать только для себя. Если вы дабавили пач, делающий что то полезное, стоит его выложить в сизиф. Оно может ещё кому-то пригодиться.
+* Делать только для себя. Если вы добавили патч, делающий что то полезное, стоит его выложить в сизиф. Оно может ещё кому-то пригодиться.
 Что нам нужно:
-* знание [[git]]. Хотя бы начальные. Вся разработка ядра ведёться в git, и его здесь ни как не обойти.
+* знание [[git]]. Хотя бы начальные. Вся разработка ядра ведётся в git, и его здесь никак не обойти.
 * Знание сборочной системы [[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
-Теперь заходим в kernel-image-2.6.25 и видим ванильное ядро. Дело в том что git cкопировал только ветку master. Посмотреть остальные ветки можно командой
+Теперь заходим в kernel-image-2.6.25 и видим ванильное ядро. Дело в том, что git cкопировал только ветку master. Посмотреть остальные ветки можно с помощью команды
   git branch -a
-И видим множетество веток. Оправившись от шока от их обилия, разберёмся зачем какая нужна.
+Оправившись от шока, вызванного обилием бранчей, разберёмся зачем каждый из них нужен.
+При ближайшем рассмотрении все бранчи можно разделить на
-При ближайшем рассмотрении все ветки можно разделить на:
 * feat-*
 * fix-*
 * 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-image-*, именно из них и собирается ядра. Таких бранчий там несколько соответвенно flavourам например пакет kernel-image-std-def собирается из одноименного бранча. остальные std-pae std-ll std-srv являются его производными и в данный момент нам не интересны. Для начала получим себе копию этого бранча
+====kernel-source====
- git checkout kernel-image-std-def -b origin/kernel-image-std-def
+- это специальный бранч из которого собирается пакет <tt>kernel-source-''версия''</tt>.
-типерь посмотрев в директорию, мы увидим spec, .gear, modules.build, subflavours и исходники ядра.
+Этот пакет всегда содержит исходники ванильного ядра, и используется для сборки всех ядер
-spec и .gear выполняют ту-же функцианальность что и в любом другом пакете.
+своей версии. Важно, что в этом пакете содержится, например, 2.6.25, а не 2.6.25.17.
-modules.build это список модулей для скриптов автоматической сборки модулей. Туда добавляются все модули которые надо пересобрать после обновления ядра
+Перед сборкой <tt>gear</tt> делает ''diff'' между тегами <tt>v2.6.''текущая верся ядра''</tt> (например, <tt>v2.6.25</tt>)
-subflavours это список subflavours которые надо обновить при обновлении основного subflavour. тоесть например мы обновляем std-def, тестируем, а потом эти изменение специальным скриптом затаскиваются в остальные subflavour
+и бранчем <tt>kernel-image-''flavour''</tt>. Этот ''diff'' кладется в SRPM,
+а при сборке вытягивается <tt>kernel-source-''версия''</tt> и на него накладывается
+этот ''diff''. Таким образом, kernel-source имеет смысл трогать, только если вы пытаетесь собрать новую версию ядра.
-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====
+- это бранчи с патчами. Они "растут" из ванильного ядра (можно базовой, вроде <tt>v2.6.25</tt>,
+можно самой свежей ванильной) и содержат патчи, добавляющие (feat) какую-то возможность или
+устраняющие какую нибудь ошибку (fix).
-fix и feat это бранчи с пачами. Они  "растут" из ванильного ядра(можно базовой (типа v2.6.25) можно, самой свежей ванильной) и содержат пачи добавляющиее(feat) какую-то возможность или устраняющие какую нибудь ошибку(fix). Далее они имееют структуру {fix,feat}-''подсистема''-''суть''. Например: fix-fs-security - устраняет уязвимости где в файлвых системах или VFS. feat-drivers-net-atl1e - добавляет драйвер для сетевой карточки atl1e.
+Далее, их названия имеют структуру <tt>{fix,feat}-''подсистема''-''суть''</tt>.
+Например, <tt>fix-fs-security</tt> устраняет уязвимости в файловых системах или VFS,
+а <tt>feat-drivers-net-atl1e</tt> добавляет драйвер для сетевой карточки atl1e.
 В общем случае:
-* в один бранч можно класть несколько пачей.
+* в один бранч можно класть несколько патчей.
 * Разные вещи лучше держать в отдельных бранчах
-* Не стоит делать бранчи на основе kernel-image-std-def. Это потом вызывает массу проблем.
+* Не стоит делать бранчи на основе <tt>kernel-image-std-def</tt>. Это потом вызывает массу проблем.
-* Если есть какие то фиксы, небходимые для мерджа или испраляющие возникающю проблему их стоит класть этот бранч.
+* Если есть какие то фиксы, необходимые для мерджа или исправляющие возникающую проблему, то их стоит класть в этот бранч.
 Про названия, примеры:
-* добавить новую wifi карточку надо feat-drivers-net-wireless-''карточка''
+* добавить новую wifi карточку надо в бранч <tt>feat-drivers-net-wireless-''карточка''</tt>
-* исправить проблему с поддержкой процссоров fix-arch-cpu-''проц''
+* исправить проблему с поддержкой процессоров - в бранч <tt>fix-arch-cpu-''проц''</tt>
 ''Добавить примеров''
-== Добавление пачей ==
+== Добавление патчей ==
-Собственно последовательность необходимая для добавление пачей.
+Собственно последовательность необходимая для добавление патчей.
-Для начала выберем имя брача, и для удобства назвовём его $branch. $vversion - это текущая весия ванильного ядра.Создаём бранч:
+Для начала выберем имя брача, и для удобства назовём его $branch. $vversion - это текущая версия ванильного ядра. Создаём бранч:
-  git checkout -b $branch v$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
@@ Строка 72: / Строка 94: @@
   git commit -a
-В git commit стоит написать описание, собтвенно что этот пач делает.
+В git commit стоит написать описание, собственно что этот патч делает.
 Ещё можно воспользоваться командой git am.
-Вышеописанное действие надо повторять, применив все необходимые пачи.
+Вышеописанное действие надо повторять, применив все необходимые патчи.
-Далее пробуем добавить наши пачи в исходные коды ядра.
+Далее пробуем добавить наши патчи в исходные коды ядра.
   git checkout kernel-image-std-def
   git merge $branch
@@ Строка 83: / Строка 105: @@
 После второй команды у нас могут возникнуть конфликты. Если они возникли их можно исправлять следующим итерационным алгоритмом.
   git status
-Увидили конфликтные файлы, выбрали один
+Увидели конфликтные файлы, выбрали один
   $EDITOR $file
-Ищим там строки >>>> , ====,  <<<< и исправляем.
+Ищем там строки >>>> , ====,  <<<< и устраняем конфликты. Так же можно воспользоваться <tt>git mergetool</tt>.
 Затем делаем
   git add $file
@@ Строка 92: / Строка 115: @@
   git commit -a
 Собственно смерджили.
-Если пач трогет фалы KConfig стоит обновить конфиги.
+Если патч трогает фалы KConfig стоит обновить конфиги.
 == Сборка и публикация ==
-Собрать ядро можно также как и любой пакет при помощи gear, только помните что пакет большой, собирается он долго, и при этом активно потребляет место.
+Собрать ядро можно, также как и любой пакет, при помощи gear, только помните что пакет большой, собирается он долго, и при этом активно потребляет место.
+{{attention|Если при сборке без видимых причин выходит с ошибкой добавление патча -- проверьте на всякий, не связано ли это с модификацией .gear/rules как _до_ того места, от которого делается патч между ванильным ядром и текущим деревом, так и уже _после_ соответствующих тегов}}
-После сборки иногда имеет смысл собрать модули, об это можно почтитать [[Сборка модулей ядра|здесь]]. Только собственно сборка просходит командой
+После сборки иногда имеет смысл собрать модули, об это можно почитать [[Сборка модулей ядра|здесь]]. Только собственно сборка происходит командой
   ./buildmodules --hasher --hsh-workdir=/home/silicium/hasher  -k std-def
-Тоесть имя модуля не указвается. И нужена ссылка kernel на git репозитарий с ядром. Посколько имя модуля не указано этот скрипт пойдёт в git репозитарий, найдет там бранч kernel-modules-std-def и в нём файл modules.build и собирёт все модули для этого ядра.
+Тоесть имя модуля не указывается. И нужна ссылка kernel на git репозиторий с ядром. Поскольку имя модуля не указано этот скрипт пойдёт в git репозиторий, найдет там бранч kernel-modules-std-def и в нём файл modules.build и соберёт все модули для этого ядра.
 Собрав ядро и модули, можно приступать к тестированию. После тестирования стоит выложить результат работы в git.
 для этого при помощи
@@ Строка 108: / Строка 133: @@
 Собственно после этого ядро все наши изменения заливаются на git.alt
-== Критерии добавления пачей в ядро std ==
+== Критерии добавления патчей в ядро std ==
-Хороший пач должен:
+Хороший патч должен:
 * Быть полезным
-* Быть переносимым (хотябы работать на x86_64 и i586)
+* Быть переносимым (хотя бы работать на x86_64 и i586)
 * Желательно быть отключаемым при загрузке или собираться модулем
 и не должен:
 * Менять работу базовых систем ядра
-* Мешать другим пачам
+* Мешать другим патчам
 * Что либо портить.
+{{Category navigation|title=Kernel|category=Kernel}}