Как обновить ядро ​​Android до последней стабильной версии Linux

nathan @ flashbox ~ / kernels / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 nathan @ flashbox ~ / kernels / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm | wc -l58 nathan @ flashbox ~ / kernels / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 arch / arm64 | wc -l22 nathan @ flashbox ~ / kernels / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | туалет -l18

Самая трудоемкая часть - это начальное воспитание; как только вы будете полностью обновлены, вам совсем не понадобится время для слияния с новым выпуском, который обычно содержит не более 100 коммитов. Однако преимущества, которые это дает (большая стабильность и лучшая безопасность для ваших пользователей), должны требовать этого процесса.

Как объединить стабильное ядро ​​Linux с ядром Android

Для начала вам нужно выяснить, с какой версией ядра работает ваше Android-устройство.

Каким бы тривиальным это ни казалось, необходимо знать, с чего вам нужно начать. Выполните следующую команду в дереве ядра:

сделать версию ядра

Он вернет ту версию, которую вы используете. Первые два числа будут использоваться для определения нужной вам ветки (например, linux-4.4.y для любого ядра 4.4), а последний номер будет использоваться для определения того, с какой версии вам нужно начать слияние (например, если вы используете 4.4 .21, далее вы объедините 4.4.22).

Загрузите последний исходный код ядра с kernel.org

kernel.org содержит последний исходный код ядра в стабильный репозиторий linux . Внизу страницы будут три ссылки для получения. По моему опыту, зеркало Google обычно самое быстрое, но ваши результаты могут отличаться. Выполните следующие команды:

git remote add linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit fetch linux-stable

Решите, хотите ли вы объединить все ядро ​​или выбрать коммиты.

Затем вам нужно будет выбрать, хотите ли вы объединить коммиты или выбрать вишню. Вот плюсы и минусы каждого, и когда вы можете захотеть их сделать.

ЗАМЕТКА: Если ваш исходный код ядра находится в форме tarball, вам, скорее всего, потребуется выборочно, иначе вы получите тысячи конфликтов файлов, потому что git заполняет историю исключительно на основе восходящего потока, а не того, что изменили OEM или CAF. Просто переходите к шагу 4.

Сбор вишни:

Плюсы:

• Легче разрешать конфликты, так как вы точно знаете, какой конфликт вызывает проблему.
• Легче перебазировать, так как каждая фиксация выполняется сама по себе.
• Легче разделить пополам при возникновении проблем

Минусы:

• Это занимает больше времени, так как каждый коммит нужно выбирать индивидуально.
• Немного сложнее с первого взгляда определить, совершена ли фиксация из восходящего потока

Идти

Плюсы :

• Это быстрее, так как вам не нужно ждать, пока все чистые исправления объединятся.
• Легче увидеть, когда фиксация сделана из апстрима, поскольку вы не будете коммиттером, а сопровождающий апстрима будет.

Минусы:

• Разрешение конфликтов может быть немного сложнее, так как вам нужно будет найти, какая фиксация вызывает конфликт, с помощью git log / git blame, он не скажет вам напрямую.
• Ребазинг сложен, поскольку вы не можете перебазировать слияние, оно предложит выбрать все коммиты по отдельности. Однако вам не следует часто выполнять ребазирование, вместо этого используйте git revert и git merge, где это возможно.

Я бы рекомендовал сделать выборку, чтобы сначала выяснить любые конфликты проблем, выполнить слияние, а затем отменить фиксацию проблемы впоследствии, чтобы обновление стало проще (поскольку слияние происходит быстрее после обновления).

Добавляйте коммиты в свой источник, по одной версии за раз

Самая важная часть этого процесса - одна версия за раз. В вашей серии апстрима МОЖЕТ быть исправление проблемы, которое может вызвать проблему с загрузкой или сломать что-то вроде звука или зарядки (объяснено в разделе советов и приемов). По этой причине важно вносить инкрементные изменения версии, легче найти проблему в 50 фиксациях, чем в более чем 2000 фиксациях для некоторых версий. Я бы рекомендовал выполнять полное слияние только после того, как вы узнаете все коммиты проблем и разрешения конфликтов.

Сбор вишни

Формат:

git cherry-pick ..

Пример:

git cherry-pick v3.10.73..v3.10.74

Идти

Формат:

иди слиться

Пример:

git merge v3.10.74

Я рекомендую отслеживать конфликты в коммитах слияния, удаляя маркеры #.

Как разрешать конфликты

Мы не можем дать пошаговое руководство по разрешению каждого отдельного конфликта, поскольку оно требует хорошего знания языка C, но вот несколько советов.

Если вы выполняете слияние, выясните, какая фиксация вызывает конфликт. Вы можете сделать это одним из двух способов:

1. git log -p v $ (make kernelversion) .. чтобы получить изменения между вашей текущей версией и последней из апстрима. Флаг -p предоставит вам изменения, сделанные каждой фиксацией, чтобы вы могли видеть.
2. Запустите git blame для файла, чтобы получить хэши каждого коммита в этой области. Затем вы можете запустить git show –format = fuller, чтобы узнать, был ли коммиттер из основной / стабильной версии, Google или CodeAurora.

• Выясните, есть ли у вас фиксация. Некоторые поставщики, такие как Google или CAF, будут пытаться искать критические ошибки, такие как исправление Dirty COW, и их резервные копии могут конфликтовать с исходными. Вы можете запустить git log –grep = ”” и посмотреть, вернет ли он что-нибудь. Если это так, вы можете пропустить фиксацию (при выборе вишни с помощью git reset –hard && git cherry-pick –continue) или игнорировать конфликты (удалить<<<<<>>>>>).
• Выясните, не было ли обратного порта, мешающего разрешению. Google и CAF хотят перенести некоторые патчи, которых не было в стабильной версии. В Stable часто требуется адаптировать разрешение основного коммита к отсутствию определенных исправлений, которые Google выбирает для резервного копирования. Вы можете посмотреть на основной коммит, запустив git show (хеш основной линии будет доступен в сообщении о фиксации стабильного коммита). Если есть обратный порт, который мешает, вы можете либо отменить изменения, либо использовать основную версию (что вам обычно нужно делать).
• Прочтите, что пытается сделать коммит, и посмотрите, устранена ли проблема. Иногда CAF может исправить ошибку независимо от апстрима, то есть вы можете либо перезаписать их исправление для апстрима, либо отказаться от него, как указано выше.

В противном случае это может быть просто результатом добавления CAF / Google / OEM, и в этом случае вам просто нужно перетасовать некоторые вещи.

Вот это зеркало стабильного linux репозитория kernel.org на GitHub, что может быть проще для поиска списков коммитов и различий для разрешения конфликтов. Я рекомендую сначала перейти к просмотру списка коммитов и найти проблемный коммит, чтобы увидеть исходный diff и сравнить его с вашим.

Пример URL: https://github.com/nathanchance/linux-stable/commit/linux-3.10.y/arch/arm64/mm/mmu.c

Вы также можете сделать это через командную строку:

git log .. git show

Решение решений зависит от контекста. Что вы должны ВСЕГДА делать, так это убедиться, что ваш окончательный результат сравнения соответствует исходному, выполнив следующие команды в двух отдельных окнах:

git diff HEAD git diff v $ (сделать версию ядра) .. $ (git tag --sort = -taggerdate -l v $ (make kernelversion | cut -d. -f 1,2) * | head -n1)

Включить rerere

В Git есть функция под названием rerere (расшифровывается как Reuse Recorded Resolution), что означает, что при обнаружении конфликта он записывает, как вы его разрешили, чтобы вы могли повторно использовать его позже. Это особенно полезно как для хронических ребазеров со слиянием, так и с выбором вишни, так как вам просто нужно будет запустить git add. && git –continue при повторном воспроизведении восходящего вызова, поскольку конфликт будет разрешен так, как вы разрешили его ранее.

Его можно включить, выполнив следующую команду в репозитории ядра:

git config rerere.enabled true

Как выполнить git bisect при запуске с ошибкой компилятора или во время выполнения

Учитывая, что вы будете добавлять значительное количество коммитов, вы вполне можете ввести ошибку компилятора или времени выполнения. Вместо того, чтобы просто сдаваться, вы можете использовать встроенный в git инструмент пополам, чтобы выяснить первопричину проблемы! В идеале вы будете собирать и обновлять каждую версию ядра по мере ее добавления, поэтому деление пополам займет меньше времени, если это необходимо, но вы можете без проблем разделить пополам 5000 коммитов.

Что будет делать git bisect, так это взять диапазон коммитов, от того, где есть проблема, до того, где ее не было, а затем начать уменьшать вдвое диапазон коммитов, что позволит вам создавать и тестировать и сообщать ему, хорошо это или нет . Он будет продолжать это до тех пор, пока не выплюнет фиксацию, вызывающую вашу проблему. На этом этапе вы можете исправить это или отменить.

1. Начать деление пополам: git bisect start
2. Отметьте текущую версию как плохую: git bisect bad
3. Отметить ревизию как хорошую: git bisect good
4. Сборка с новой версией
5. В зависимости от результата (присутствует проблема или нет) скажите git: git bisect good ИЛИ git bisect bad
6. Промойте и повторяйте шаги 4-5, пока не будет обнаружена фиксация проблемы!
7. Отменить или исправить фиксацию проблемы.

ЗАМЕТКА: При слияниях потребуется временно запустить git rebase -i, чтобы применить все патчи к вашей ветке для правильного деления пополам, поскольку деление пополам с выполненными слияниями часто приводит к проверке на восходящие коммиты, что означает, что у вас нет никаких коммитов, специфичных для Android. Я могу более подробно остановиться на этом по запросу, но поверьте мне, это необходимо. Как только вы определили фиксацию проблемы, вы можете отменить ее или перебазировать в слияние.

НЕ скручивайте апстрим-обновления

Многие новые разработчики склонны делать это, поскольку это «чище» и «проще» в управлении. Это ужасно по нескольким причинам:

• Авторство потеряно. По отношению к другим разработчикам несправедливо получать кредиты за их работу.
• Деление пополам невозможно. Если вы раздавили серию коммитов, и в этой серии есть проблема, невозможно сказать, какая фиксация вызвала проблему в сквоше.
• В будущем сделать выбор сложнее. Если вам нужно выполнить перебазирование с помощью сжатой серии, трудно / невозможно определить, откуда возникает конфликт.

Подпишитесь на список рассылки ядра Linux для получения своевременных обновлений

Чтобы получать уведомления о новых обновлениях, подпишитесь на список linux-kernel-announce . Это позволит вам получать электронное письмо каждый раз при выпуске нового ядра, чтобы вы могли обновлять и загружать его как можно быстрее.