Вход:  Пароль:  
FreeSource: AltLinux/Sisyphus/devel/kernelnotes ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |
Это старая версия AltLinux/Sisyphus/devel/kernelnotes за 2007-11-15 10:34:50..

Собираем новое ядро


Например я буду собирать ядро версии 2.6.23. Нижеследующие примеры будут относится к ядру этой версии.
Вам понадобится хорошая быстрая машина, с быстрым процессором, и большим обемом ОЗУ.
У автора ЦПУ Athlon 64 X2 Dual Core 3800+ 1GB ОЗУ, по субьективной оценке, не очень быстро работали.
Для более быстрой сборки vsu рекомендует использовать ccache, установив перед этим в переменные:


$ export LC_ALL=C
$ export GCC_USE_CCACHE=1 

Подготовительный этап

У ALT Linux разработана своя среда (kernel-build-scripts) для сборки ядер. Основным мантейнером этой среды является vsu.
Я рекомендую скачать kernel-build-scripts непосредственно с репозитария vsu:

$ git-clone http://git.altlinux.org/people/vsu/packages/kernel-build-scripts.git kernel-build-scripts.git
$ cd kernel-build-scripts.git
$ ls 

Как видно, среда состоит из набора скриптов. Рекомендую ознакомится с файлом README.koi8, где описана вся кухня по сборке ядра.
Существует два вида скриптов, *-hsh собирают через hasher, другие – без.
Если вы будете собирать пакеты без помощи hasher, тогда необходимо скопировать пакеты kernel-source-* в папку source.
Там это распаковывается в tmp/root и используется для сборки, без установки в систему, и без создания chroot, прочие buildrequires нужно удовлетворить как обычно.

II 

Пакеты ядра и модулей для дистрибутива ALT Linux как минимум собирает vsu или lakostis (может кто-то еще, я не вкурсе).
Нам нужно забрать у них ихние наработки.
Репозитарий c ядром должен находится в папке: kernel-build-script.git/kernel
Забираем ядро у vsu или lakostis:

$ git-clone --origin vsu http://git.altlinux.org/people/vsu/packages/kernel-image-2.6.18.git kernel
или
$ git-clone --origin lakostis http://git.altlinux.org/people/lakostis/packages/kernel-image-2.6.22.git kernel 

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

$ git remote add linux-2.6.23 git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git 

В master ветку этого репозитория, Linus помещает обновления для ядер серии 2.6.23 (например 2.6.23.1, 2.6.23.2,....)
Будет создана ветка linux-2.6.23/master, которая будет отслеживать обновления для ванильного ядра 2.6.23.


Загрузим с репозитория linux-2.6.23 исходных код ядра.

$ git fetch linux-2.6.23 

Теперь в нашем репозитории ветка linux-2.6.23/master содержит ядро 2.6.23 с обновлениями.
Убедимся:

$ git-log --pretty=short -n 1 linux-2.6.23/master
commit 4367388f04eea72e78347dc9b299698bf4275f92
Author: Greg Kroah-Hartman <gregkh@suse.de>

    Linux 2.6.23.1 

Собрираем пакет kernel-source-2.6.23–1.0.0-alt1.noarch.rpm

Как видно, данный пакет не зависит от архитектуры.
Внутри пакета содержиться только файл с иходными кодами ванильного ядра:
/usr/src/kernel/sources/kernel-source-2.6.23.tar.bz2
Заметьте, что данный пакет содержит исходный код ядра версии 2.6.23, а не 2.6.23.1.
Собрать этот пакет не составит труда. Достаточно:

$ git-checkout -b kernel-source vsu/kernel-source 

Сделать: иначе будет ругаться gear

$ git pull -s ours . tag v2.6.23
$ vim kernel-source.spec
$ add_changelog kernel-source.spec 

В ответ на ругань add_changelog что версия пакета не изменилась, можно добавить к alt1 точку: 'alt1.', потом удалить.
Версия пакета не изменяется, а изменяется имя пакета.
Обновить версию ядра в файле .gear-rules

$ gear-update-tag -a -c
$ git-add .gear-rules kernel-source.spec
$ git commit -m "kernel-source-2.6.23 1.0.0-alt1" 

Осталось собрать сам пакет с помощью gear в hasher:

$ gear --hasher -- hsh 

Замечания вида:
warning: Macro %kernel_srcdir not found
warning: Macro %kernel_srcdir not found
warning: Macro %kernel_src not found
на результат не влияет, там Build Requires?(pre) не хватает.
После сборки этот пакет будет находится в репозитории hasher-a.

Собираем пакет kernel-image-std-smp-2.6.23-alt1.i586.rpm

Собственно этот пакет содержит само ядро + стандартные модули поставляемые с ядром.


В моем случае, накатывать 2.6.23 поверх пропатченого 2.6.18, бесмысленно, иначе там всё развалится.
Придётся делать по сути rebase всех веток с патчами, а подцеплять к старой истории в самом конце.
При сборке 2.6.23 лучше создать новые ветки fix-stable, kernel-image-std-smp, ...

A

Cоздадим ветку fix-stable. Задача этой ветки содержать последние официальные исправления для ядра от Linus:

$ git checkout -b fix-stable linux-2.6.23/master 

При будущих обновлениях можно поступать одним из следующим способов:
1. Из tracking branch:

$ git fetch linux-2.6.23
$ git-pull . linux-2.6.23/master 

2. Непосредственно из репозитория Linus-а:

$ git pull git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.23.y.git 

Несколько слов о структуре репозитария.
На мой взгляд следует различать ветки:

Имя ветки сообщает, какое конкретное дополнение она несет.

Цель ветки kernel-image-std-smp создать мега патч-бомбу который накладывается на ванильное ядро 2.6.23 и скомпилировать бинарное ядро.
Файл branches-to-merge используется скриптом merge-all-branches.
Может возникнуть вопрос: «Зачем мержить ветки которые указаны в branches-to-merge, если они уже в замерженыы в ветку kernel-image-std-smp ?"
Ответ: Периодически в этих ветках появляется что-то новое, вот скрипт и проверяет, что появилось. Ещё возможен вариант вида branch-*
скрипт merge-all-branches проверяет, есть ли что-то новое, если нет – ничего не делает, если есть – спрашивает, надо ли это мержить.


B

Создадим ветку kernel-image-std-smp на основе тега v2.6.23. Задача этой ветки содержать код ядра со всеми приложеными патчами.
Т.е. в эту ветку мержатся остальные ветки feat-*-* fix-*-*.

$git checkout -b kernel-image-std-smp v2.6.23 

Заберем из старой ветки vsu/kernel-image-std-smp файлы:
kernel-image.spec
config-i586
config-x86_64
branches-to-merge
.gear-rules
modules.build


$ git-ls-tree vsu/kernel-image-std-smp
$ git cat-file blob 'sha1' >kernel-image.spec
$ git-add -f kernel-image.spec config-i586 config-x86_64 branches-to-merge .gear-rules modules.build 

флаг -f указывает добавить .gear-rules, даже если он занесен в .gitignore

C

Создадим ветки feat-*-* и fix-*-*. Например создадим ветку добавляющую поддержку файловой системы unioinfs.

$ git-checkout -b feat-fs-unionfs v2.6.23 

патч можно наложить в ручную (patch -p1 < .....) или же средствами git. Что будет более правильно, и облегчит добавление файлов в index,
если патч затрагивает слишком много файлов:

$ git-apply --index --whitespace=nowarn p1.patch 

Отличие от patch в том, что git apply рассматривает любой fuzz как ошибку.
Ещё особенность в том, что по умолчанию, если есть хотя бы одна ошибка, патч не применяется вообще
Можно добавить reject, чтобы создавались *.rej, как с обычным patch.
Кстати, такой внешний патч может иметь смысл совать в отдельную ветку, растущую прямо из той версии ядра, для которой предназначен патч
а потом уже мержить дело в том, что 3way merge зачастую работает надёжнее, чем наложение патча на изменившуюся версию
изменения из патча иногда могут молча улетать в другой участок с похожим содержимым.

$ commit -m "Add unionfs 2.1.8 support" 

Ничего страшного не будет если самому создать сам ветку git checkout -b fix-xxx, а потом добавить коммит из ветки vsu/fix-xxx с помощью git cherry-pick.
vsu так же делал большей части этих веток. Т.е. получается мы крадем коммиты vsu с помощью cherry-pick.
Единственная неприятность от cherry-pick – если эти коммиты появятся в нескольких местах, потом, возможно, придётся что-то мержить руками.
Если изменения точно совпадают, git merge происходит автоматически, если с одной стороны есть ещё какие-то изменения сверху, может вылезти конфликт на ровном месте


Если Linux добавил в официальное ядро исправления то можно сделать в ветке fix-stable

$ git pull -s ours fix-xxx 

этот фиктивный мерж проходит всегда автоматом, а потом git уже просто не смотрит внутрь этой ветки.


В итоге у меня получились следующие ветки :

feat-corert
feat-core-bootsplash
feat-evms
feat-evms-nodm
feat-fs-squashfs
feat-fs-unionfs
fix-coreinit
fix-core
syslog
fix-stable
kernel-image-std-smp
kernel-source
master

D

Мержим все исправления в ветку kernel-image-std-smp, исправляем конфликты.

$ git-pull . feat-fs-unionfs 

E

В ветке kernel-image-std-smp, создадим новый конфиг на базе старого:

$ cp config-i586 .config
$ make oldconig 

При обработке make oldconfig, следует учитывать тот факт, что при наличии возможности скомпилировать некую часть ядра в виде модуля, следует ее выбрать.
Чаще всего модули не компилируются непосредственно в ядро, но бывают исключения.
Проверяем все ли впорядке

$ make menuconfig 

Опцию CONFIG_LOCALVERSION_AUTO следует откулючить.

$ cp .config config-i586
Поправить kernel-image.spec, .gear-rules,
$ add_changelog kernel-image.spec
$ git-update-tag -c -a
$ git add config-i586 kernel-image.spec .gear-rules
$ git commit 

F

Собираем ядро
$ ./buildkernel-hsh --hsh-workdir=/home/stanv/hasher std-smp

3

Сборка дополнительных модулей
$ cvs -d cvs.alt:/cvs/kernel checkout -d modules kernel/modules
или
$ cvs -d anoncvs@anoncvs.altlinux.org:/cvs/kernel co -d modules kernel/modules

Вопросы

Откуда брать эти самые kernel-source-nvidia ? как самому их построить ? – Из сизифа. В принципе эти пакеты собираются как обычно. У кого-то лежит в гите, у кого-то старым дедовским способом.
Получается что мантейниры модулей предлагают только kernel-source-modules-%module_name ......а сам бинарный модуль собираешь ти ? – Да.
поскольку его надо пересобирать при каждом обновлении ядра
а если kernel-source-modules-%module_name плохо собран.... тогда .... тогда ты выполняешь двойную работу, ну либо забиваю на этот модуль.


у нас используется patch_level_numeric ? или забили на него ? 1.0.0
фактически забили он был нужен, когда собирали pre/rc


pull . сейчас можно менять на merge
что лучше cherry-pick или pull ?
это в древних версиях git merge не предназначался для вызова руками
зависит от ситуации... если в ветке куча коммитов, которые в свежей версии уже есть, merge с большой вероятностью не пройдёт автоматически
если это патчи, которые не вошли в новую версию, вероятно, лучше сделать merge
а я сделал cherry :(
кстати, в подобном случае может иметь смысл сначала сделать merge новой версии в эту ветку
хотя это зависит от того, что в дальнейшем предполагается делать с этими изменениями
если нужно получить патчи для свежего апстрима, придётся делать rebase
если это какие-то изменения, которые апстриму нафиг не нужны, может быть проще смержить свежую версию апстрима туда и разгрести конфликты
кстати, в самом свежем git сделали поддержку revert и cherry-pick для merge... указывается, с каким родителем делать дифф, который потом откатывается или применяется
A->B ы :( т.е. cherry-pick может забирвать все коммиты, между A и B ?
нет... это git rebase умеет
только он портит исходный бранч
а в чем тогда новая фишка ?
cherry-pick и revert – это почти одно и то же, различаются тем, в какую сторону применяется патч
патч генерируется между указанным коммитом и его родителем
если это merge, нужно указать, какой из родительских коммитов нужно брать
вот эту опцию и добавили
т.е., если сделать cherry-pick для merge, получится один мегапатч со всеми изменениями
вообще это полезно для revert


 
Файлов нет. [Показать файлы/форму]
Комментариев нет. [Показать комментарии/форму]