Добавление патчей в ядро
Материал из ALT Linux Wiki
(→Добавление патчей) |
|||
(8 промежуточных версий не показаны.) | |||
Строка 1: | Строка 1: | ||
[[Категория:Devel]] | [[Категория:Devel]] | ||
[[Категория:Sisyphus]] | [[Категория:Sisyphus]] | ||
+ | [[Категория:Kernel]] | ||
+ | |||
''Эту статить надо слегка довести, и добавить ссылок'' | ''Эту статить надо слегка довести, и добавить ссылок'' | ||
== Введение == | == Введение == | ||
- | Эта статья описывает то, как добавить | + | Эта статья описывает то, как добавить патчи к нашим ядрам и вообще рассказывает о git репозитории с ядром. |
Для начала стоит понять зачем в это лезть. Цели могут быть разные: | Для начала стоит понять зачем в это лезть. Цели могут быть разные: | ||
* просто интересно. | * просто интересно. | ||
* есть функциональность, которую хотелось добавить, а в наших ядрах её нет. | * есть функциональность, которую хотелось добавить, а в наших ядрах её нет. | ||
- | * расширение поддержки железа. Есть железяка, она не работает, но есть | + | * расширение поддержки железа. Есть железяка, она не работает, но есть патч и возможность проверить. |
Почему этого не стоит делать: | Почему этого не стоит делать: | ||
Строка 14: | Строка 16: | ||
Чего не стоит делать: | Чего не стоит делать: | ||
* Плодить разные flavour. Лучше добавить к имеющимся. | * Плодить разные flavour. Лучше добавить к имеющимся. | ||
- | * Делать только для себя. Если вы добавили | + | * Делать только для себя. Если вы добавили патч, делающий что то полезное, стоит его выложить в сизиф. Оно может ещё кому-то пригодиться. |
Что нам нужно: | Что нам нужно: | ||
- | * знание [[git]]. Хотя бы начальные. Вся разработка ядра ведётся в git, и его здесь | + | * знание [[git]]. Хотя бы начальные. Вся разработка ядра ведётся в git, и его здесь никак не обойти. |
* Знание сборочной системы [[gear]] | * Знание сборочной системы [[gear]] | ||
- | * Доступ к | + | * Доступ к репозиторию. |
* Достаточно мощная машина. Ядро может собираться долго(около получаса) в зависимости от железа, и в процессе сборки потребовать до 1Gb под временные файлы. Будьте готовы что этот процесс съест много ресурсов. | * Достаточно мощная машина. Ядро может собираться долго(около получаса) в зависимости от железа, и в процессе сборки потребовать до 1Gb под временные файлы. Будьте готовы что этот процесс съест много ресурсов. | ||
- | * Доступ к git.alt. git | + | * Доступ к 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 | ||
Строка 58: | Строка 60: | ||
====fix и feat==== | ====fix и feat==== | ||
- | - это бранчи с | + | - это бранчи с патчами. Они "растут" из ванильного ядра (можно базовой, вроде <tt>v2.6.25</tt>, |
- | можно самой свежей ванильной) и содержат | + | можно самой свежей ванильной) и содержат патчи, добавляющие (feat) какую-то возможность или |
устраняющие какую нибудь ошибку (fix). | устраняющие какую нибудь ошибку (fix). | ||
Строка 67: | Строка 69: | ||
В общем случае: | В общем случае: | ||
- | * в один бранч можно класть несколько | + | * в один бранч можно класть несколько патчей. |
* Разные вещи лучше держать в отдельных бранчах | * Разные вещи лучше держать в отдельных бранчах | ||
* Не стоит делать бранчи на основе <tt>kernel-image-std-def</tt>. Это потом вызывает массу проблем. | * Не стоит делать бранчи на основе <tt>kernel-image-std-def</tt>. Это потом вызывает массу проблем. | ||
Строка 74: | Строка 76: | ||
Про названия, примеры: | Про названия, примеры: | ||
* добавить новую wifi карточку надо в бранч <tt>feat-drivers-net-wireless-''карточка''</tt> | * добавить новую wifi карточку надо в бранч <tt>feat-drivers-net-wireless-''карточка''</tt> | ||
- | * исправить проблему с поддержкой | + | * исправить проблему с поддержкой процессоров - в бранч <tt>fix-arch-cpu-''проц''</tt> |
''Добавить примеров'' | ''Добавить примеров'' | ||
- | == Добавление | + | == Добавление патчей == |
Собственно последовательность необходимая для добавление пачей. | Собственно последовательность необходимая для добавление пачей. | ||
- | Для начала выберем имя брача, и для удобства | + | Для начала выберем имя брача, и для удобства назовём его $branch. $vversion - это текущая версия ванильного ядра. Создаём бранч: |
- | git checkout -b $branch v$ | + | 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 | ||
Строка 90: | Строка 92: | ||
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 | ||
Строка 101: | Строка 103: | ||
После второй команды у нас могут возникнуть конфликты. Если они возникли их можно исправлять следующим итерационным алгоритмом. | После второй команды у нас могут возникнуть конфликты. Если они возникли их можно исправлять следующим итерационным алгоритмом. | ||
git status | git status | ||
- | + | Увидели конфликтные файлы, выбрали один | |
$EDITOR $file | $EDITOR $file | ||
- | + | Ищем там строки >>>> , ====, <<<< и устраняем конфликты. Так же можно воспользоваться <tt>git mergetool</tt>. | |
Затем делаем | Затем делаем | ||
Строка 111: | Строка 113: | ||
git commit -a | git commit -a | ||
Собственно смерджили. | Собственно смерджили. | ||
- | Если | + | Если патч трогает фалы KConfig стоит обновить конфиги. |
== Сборка и публикация == | == Сборка и публикация == | ||
- | Собрать ядро можно также как и любой пакет при помощи gear, только помните что пакет большой, собирается он долго, и при этом активно потребляет место. | + | Собрать ядро можно, также как и любой пакет, при помощи gear, только помните что пакет большой, собирается он долго, и при этом активно потребляет место. |
- | После сборки иногда имеет смысл собрать модули, об это можно | + | После сборки иногда имеет смысл собрать модули, об это можно почитать [[Сборка модулей ядра|здесь]]. Только собственно сборка происходит командой |
./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 и соберёт все модули для этого ядра. |
Собрав ядро и модули, можно приступать к тестированию. После тестирования стоит выложить результат работы в git. | Собрав ядро и модули, можно приступать к тестированию. После тестирования стоит выложить результат работы в git. | ||
для этого при помощи | для этого при помощи | ||
Строка 127: | Строка 129: | ||
Собственно после этого ядро все наши изменения заливаются на git.alt | Собственно после этого ядро все наши изменения заливаются на git.alt | ||
- | == Критерии добавления | + | == Критерии добавления патчей в ядро std == |
- | Хороший | + | Хороший патч должен: |
* Быть полезным | * Быть полезным | ||
- | * Быть переносимым ( | + | * Быть переносимым (хотя бы работать на x86_64 и i586) |
* Желательно быть отключаемым при загрузке или собираться модулем | * Желательно быть отключаемым при загрузке или собираться модулем | ||
и не должен: | и не должен: | ||
* Менять работу базовых систем ядра | * Менять работу базовых систем ядра | ||
- | * Мешать другим | + | * Мешать другим патчам |
* Что либо портить. | * Что либо портить. | ||
+ | |||
+ | |||
+ | {{Category navigation|title=Kernel|category=Kernel}} |
Текущая версия на 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)
- Желательно быть отключаемым при загрузке или собираться модулем
и не должен:
- Менять работу базовых систем ядра
- Мешать другим патчам
- Что либо портить.