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

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


Почему этого не стоит делать:
Почему этого не стоит делать:
Строка 13: Строка 18:
Чего не стоит делать:
Чего не стоит делать:
* Плодить разные flavour. Лучше добавить к имеющимся.
* Плодить разные 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-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
  git checkout -b feat-driver-net-atl1e v2.6.25


Теперь приложим пач. Его можно либо приложить и закомитить. Тоесть:
Теперь приложим патч. Его можно либо приложить и закомитить. Тоесть:
  patch -p$n < $patch
  patch -p$n < $patch
  find -name "*.orig"|xargs rm -f
  find -name "*.orig"|xargs rm -f
Строка 72: Строка 94:
  git commit -a
  git commit -a


В git commit стоит написать описание, собтвенно что этот пач делает.
В git commit стоит написать описание, собственно что этот патч делает.
Ещё можно воспользоваться командой git am.  
Ещё можно воспользоваться командой git am.  


Вышеописанное действие надо повторять, применив все необходимые пачи.
Вышеописанное действие надо повторять, применив все необходимые патчи.


Далее пробуем добавить наши пачи в исходные коды ядра.
Далее пробуем добавить наши патчи в исходные коды ядра.
  git checkout kernel-image-std-def
  git checkout kernel-image-std-def
  git merge $branch
  git merge $branch
Строка 83: Строка 105:
После второй команды у нас могут возникнуть конфликты. Если они возникли их можно исправлять следующим итерационным алгоритмом.
После второй команды у нас могут возникнуть конфликты. Если они возникли их можно исправлять следующим итерационным алгоритмом.
  git status
  git status
Увидили конфликтные файлы, выбрали один
Увидели конфликтные файлы, выбрали один
  $EDITOR $file
  $EDITOR $file
Ищим там строки >>>> , ====,  <<<< и исправляем.
Ищем там строки >>>> , ====,  <<<< и устраняем конфликты. Так же можно воспользоваться <tt>git mergetool</tt>.
 
Затем делаем   
Затем делаем   
  git add $file
  git add $file
Строка 92: Строка 115:
  git commit -a
  git commit -a
Собственно смерджили.
Собственно смерджили.
Если пач трогет фалы KConfig стоит обновить конфиги.
Если патч трогает фалы KConfig стоит обновить конфиги.


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


После сборки иногда имеет смысл собрать модули, об это можно почтитать [[Сборка модулей ядра|здесь]]. Только собственно сборка просходит командой  
После сборки иногда имеет смысл собрать модули, об это можно почитать [[Сборка модулей ядра|здесь]]. Только собственно сборка происходит командой  
  ./buildmodules --hasher --hsh-workdir=/home/silicium/hasher  -k std-def
  ./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.
Собрав ядро и модули, можно приступать к тестированию. После тестирования стоит выложить результат работы в git.
для этого при помощи
для этого при помощи
Строка 108: Строка 133:
Собственно после этого ядро все наши изменения заливаются на git.alt
Собственно после этого ядро все наши изменения заливаются на git.alt


== Критерии добавления пачей в ядро std ==
== Критерии добавления патчей в ядро std ==
Хороший пач должен:
Хороший патч должен:
* Быть полезным
* Быть полезным
* Быть переносимым (хотябы работать на x86_64 и i586)
* Быть переносимым (хотя бы работать на x86_64 и i586)
* Желательно быть отключаемым при загрузке или собираться модулем
* Желательно быть отключаемым при загрузке или собираться модулем


и не должен:
и не должен:
* Менять работу базовых систем ядра
* Менять работу базовых систем ядра
* Мешать другим пачам
* Мешать другим патчам
* Что либо портить.
* Что либо портить.
{{Category navigation|title=Kernel|category=Kernel}}

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

и не должен:

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