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

Мы рассмотрели руководства по ядрам Android, такие как «Как создать собственное ядро» и «Лучшие кастомные ядра для Android», но сегодня мы собираемся показать вам, как использовать ядро против последней стабильной версии Linux.

Пожалуйста, знайте, что это передовой материал — если вы никогда раньше не компилировали ядро, вам следует следовать руководству «Как создать собственное ядро», которое приведено выше, и это руководство будет включать сбор вишни и слияние коммитов из последнего стабильного ядра Linux с вашим ядром Android прежде чем скомпилировать.

Обновление ядра Android до последней стабильной версии Linux имеет много положительных преимуществ, таких как наличие последних обновлений безопасности и исправлений ошибок — некоторые плюсы и минусы мы объясним позже в этом руководстве.

Что такое ядро Linux-Stable?

Linux-stable, как следует из названия, является стабильной ветвью ядра Linux. Другая рука известна как «основная линия», которая является основной ветвью. Вся разработка ядра Linux происходит в основном, и обычно следует этому процессу:

Линус Торвальдс получит несколько патчей от своих сопровождающих в течение двух недель.
После этих двух недель он выпускает ядро rc1 (например, 4.14-rc1).
На каждую неделю в течение следующих 6-8 недель он выпускает другое ядро RC (например, 4.14-rc2, 4.14-rc3 и т. Д.), Которое содержит ТОЛЬКО исправления ошибок и регрессии.
Как только он будет считаться стабильным, он будет выпущен в виде архива для загрузки в org (например, 4.14).

Что такое ядра LTS?

Каждый год Грег выбирает одно ядро и поддерживает его в течение двух лет (LTS) или шести лет (расширенный LTS). Они предназначены для продуктов, которым требуется стабильность (например, телефоны Android или другие устройства IOT). Процесс такой же, как и выше, просто это происходит дольше. В настоящее время существует шесть ядер LTS (которые всегда можно посмотреть на странице релизов kernel.org):

4.14 (LTS), поддерживается Грег Кроа-Хартман
4.9 (LTS), поддерживается Грег Кроа-Хартман
4.4 (eLTS), поддерживается Грег Кроа-Хартман
4.1 (LTS), поддерживается Сашей Левиным
3.16 (LTS), поддерживается Беном Хатчингсом
3.2 (LTS), поддерживается Беном Хатчингсом

Каковы преимущества перехода моего ядра Android на Linux Stable?

Когда важные уязвимости обнаруживаются / исправляются, стабильные ядра получают их первыми. Таким образом, ваше ядро Android будет намного безопаснее от атак, недостатков безопасности и просто ошибок в целом.

Стабильная версия Linux включает в себя исправления для многих драйверов, которые мое устройство Android не использует, не является ли это в основном ненужным?

Да и нет, в зависимости от того, как вы определяете «в основном». Ядро Linux может содержать много кода, который не используется в системе Android, но это не гарантирует, что при слиянии новых версий не будет конфликтов с этими файлами! Поймите, что практически никто не собирает каждую часть ядра, даже самые распространенные дистрибутивы Linux, такие как Ubuntu или Mint. Это не значит, что вы не должны принимать эти исправления, потому что ЯВЛЯЮТСЯ исправления для водителей вы ДЕЛАТЬ запустить. Возьмем, например, arm / arm64 и ext4, которые являются наиболее распространенной архитектурой Android и файловой системой соответственно. В 4.4 с 4.4.78 (версия последнего тега Oreo CAF) до 4.4.121 (последний восходящий тег) это следующие цифры для коммитов этих систем:

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 | туалет -18

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

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

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

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

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

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

Получить последний исходный код ядра от kernel.org

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

git remote добавить linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit получить linux-stable

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

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

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

Вишневый Сбор урожая:

Плюсы:

Проще разрешать конфликты, поскольку вы точно знаете, какой конфликт вызывает проблему.
Проще перебазировать, так как каждый коммит сам по себе.
Проще разделить пополам, если возникнут проблемы

Минусы:

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

сливаться

Pros:

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

Минусы:

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

Я бы порекомендовал сделать «черри-пик», чтобы сначала выяснить какие-либо конфликты проблем, выполнить слияние, а затем отменить исправления проблем после этого, чтобы упростить обновление (так как слияние происходит быстрее после обновления).

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

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

Вишневый Сбор урожая

Формат:

мерзкая вишня

Пример:

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

сливаться

Формат:

мерзавец слияния

Пример:

Git Merge v3.10.74

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

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

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

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

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

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

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

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

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

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

мерзавец журнал ..
мерзавец

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

git diff HEAD
git diff v $ (создание версии ядра) .. $ (тег git --sort = -taggerdate -l v $ (создание версии ядра | cut -d. -f 1,2) * | head -n1)

Включить rerere

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

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

git config rerere.enabled true

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

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

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

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

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

НЕ давите обновления вверх по течению

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

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

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

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