Як оновити ядро ​​Android на найновіший Linux Stable

Ми розглянули посібники з ядер Android, наприклад "Як створити користувацьке ядро" та "Найкращі спеціальні ядра для Android", але сьогодні ми покажемо вам, як передати ваше ядро ​​проти останньої стабільної версії Linux.

Будь ласка, знайте, що це розширений матеріал - якщо ви ніколи раніше не компілювали ядро, слід дотримуватися посібника "Як створити користувальницьке ядро", зв'язаного вище, і цей посібник буде включати в себе збирання вишень та об'єднання комісій з останніх Linux- стабільне ядро ​​з вашим ядром Android, перш ніж його компілювати.

Оновлення ядра Android до останньої стабільної версії Linux має багато позитивних переваг, наприклад, бути в курсі останніх зобов’язань щодо безпеки та виправлень - ми пояснимо деякі плюси та мінуси пізніше в цьому посібнику.

Що таке Linux-стабільне ядро?

Стабільний для Linux, як випливає з назви, є стабільною рукою ядра Linux. Інша рука відома як "магістраль", яка є основною гілкою . Вся розробка ядра Linux відбувається в основному рядку і, як правило, слідує за цим процесом:

1. Лінус Торвальдс за два тижні візьме купу латок у своїх супроводжувачів.
2. Після цього два тижні він випускає ядро ​​rc1 (наприклад, 4.14-rc1).
3. Кожен тиждень протягом наступних 6-8 тижнів він випускатиме ще одне ядро ​​RC (наприклад, 4.14-rc2, 4.14-rc3 тощо), яке містить ТОЛЬКІ виправлення помилок та регресії.
4. Як тільки він буде визнаний стабільним, він буде випущений як тарбол для завантаження на 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 (останній тег висхідного потоку), це наступні номери для комітетів цих систем:

 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 арка / рука | wc -l58 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 арка / arm64 | wc -l22 ~ / kernel / linux-stable (master) $ git log --format =% h v4.4.78..v4.4.121 fs / ext4 | wc -l18 

Найбільш трудомістка частина - це початкове піднесення; після того, як ви будете до кінця оновлені, для злиття нового випуску не потрібно часу, який зазвичай містить не більше 100 комітетів. Переваги, які це приносить (більша стабільність та краща безпека для ваших користувачів), повинні потребувати цього процесу.

Як об'єднати стабільне ядро ​​Linux в ядро ​​Android

Спочатку потрібно розібратися, у якій версії ядра працює ваш пристрій Android.

Настільки тривіально, як це здається, потрібно знати, з чого потрібно почати. Виконайте таку команду у вашому дереві ядра:

 зробити ядроверсію 

Він поверне версію, на якій ви працюєте. Перші два числа будуть використані для визначення потрібної вам гілки (наприклад, linux-4.4.y для будь-якого ядра 4.4), а останнє число буде використано для визначення версії, яку потрібно починати з об'єднання (наприклад, якщо ви перебуваєте на 4.4 .21, ви злите 4.4.22 далі).

Візьміть останнє джерело ядра від kernel.org

kernel.org зберігає останнє джерело ядра в стабільному Linux-сховищі. Внизу цієї сторінки будуть три посилання для отримання. На мій досвід, дзеркало Google, як правило, найшвидше, але ваші результати можуть відрізнятися. Виконайте такі команди:

 git віддалений додати стабільний Linux //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit вибір linux-stable 

Вирішіть, чи хочете ви об'єднати ціле ядро ​​чи вишню комітетів

Далі вам потрібно буде вибрати, чи хочете ви об'єднати комітети чи вишневий вибір. Ось плюси і мінуси кожного, і коли ви можете їх виконати.

ПРИМІТКА. Якщо джерело вашого ядра у формі тарболу, вам, швидше за все, потрібно буде вибирати вишню, інакше у вас вийдуть тисячі конфліктів файлів, оскільки git заповнює історію, засновану виключно на течії, а не на OEM чи CAF. змінився. Просто перейдіть до кроку 4.

Збір вишні:

Плюси:

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

Мінуси:

• Це займає більше часу, оскільки кожне зобов’язання потрібно вибирати індивідуально.
• Трохи складніше сказати, чи здійснюють з першого погляду фіксацію

Злиття

Плюси :

• Це швидше, тому що вам не доведеться чекати, коли всі чисті патчі злиться.
• Легше зрозуміти, коли комісія відбувається з вищого потоку, оскільки ви не будете виконавцем, а підтримкою верхнього потоку буде.

Мінуси:

• Вирішення конфліктів може бути дещо складнішим, оскільки вам потрібно буде шукати, яка комісія спричиняє конфлікт за допомогою git log / git вини, це не скаже вам прямо.
• Повторна передача є складною, оскільки ви не можете відновити об'єднання, вона запропонує вибирати всі комісії окремо. Однак, вам не слід часто відмовлятись, замість цього використовувати git revert та git merge, де це можливо.

Я рекомендую зробити вибір вишні, щоб спочатку розібратися у будь-яких проблемних конфліктах, зробити злиття, а потім повернути проблему, щоб зробити згодом, щоб оновлення було простішим (оскільки об'єднання швидше після оновлення).

Додайте зобов’язання до свого джерела, по одній версії

Найважливіша частина цього процесу - це одна версія за часом. У вашій низхідній серії може бути виправлення неполадок, що може спричинити проблеми із завантаженням або порушити щось на зразок звуку чи зарядки (пояснено в розділі порад та рекомендацій). З цього приводу важливі зміни змін версій, тому простіше знайти проблему в 50 комітах, ніж більше 2000 комісій для деяких версій. Я б рекомендував здійснити повне злиття лише після того, як ви дізнаєтесь про всі вирішення проблеми та вирішення конфліктів.

Збір вишні

Формат:

 git вишневий сік .. 

Приклад:

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

Злиття

Формат:

 git merge 

Приклад:

git merge v3.10.74

Я рекомендую відстежувати конфлікти в об'єднанні, видаляючи # маркери.

Як вирішити конфлікти

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

Якщо ви зливаєтеся, з’ясуйте, що вчинення викликає конфлікт. Зробити це можна двома способами:

1. git log -pv $ (зробити kernelversion) .., щоб отримати зміни між вашою поточною версією та останньою версією потоку. Прапор -p подасть вам зміни, здійснені кожним комітетом, щоб ви могли бачити.
2. Виконайте винуватцю git у файлі, щоб отримати хеші кожного комітету у цьому регіоні. Потім ви можете запустити git show –format = fuller, щоб дізнатись, чи виконувався він з mainline / stable, Google або CodeAurora.

• З'ясуйте, чи вже у вас є фіксація. Деякі постачальники, такі як Google або CAF, намагатимуться шукати вгору потоки критичних помилок, як-от виправлення брудної COW, і їхні опори можуть конфліктувати з вихідними. Ви можете запустити git log –grep = ”” і подивитися, чи повертає він щось. Якщо це так, ви можете пропустити фіксацію (якщо вишня вибору за допомогою git reset –hard && git cherry-pick – продовжити) або ігнорувати конфлікти (видаліть <<<<< >>>>>).
• З'ясуйте, чи був резервний порт, який заплутав дозвіл. Google і CAF люблять підтримувати певні виправлення, які стабільно не могли б. Стабільній часто потрібно буде адаптувати роздільну здатність основної лінії до відсутності певних виправлень, які Google вирішує підтримувати. Ви можете переглянути фіксацію основної лінії, запустивши git show (хеш основного рядка буде доступний у повідомленні про стабільну фіксацію). Якщо резервний порт зіпсував його, ви можете скасувати зміни або скористатися основною версією (що зазвичай потрібно зробити).
• Прочитайте, що коміт намагається зробити і перевірте, чи проблема вже виправлена. Іноді CAF може виправити помилку, незалежну від висхідної течії, тобто ви можете замінити їх виправлення на верхній потік або відкинути його, як вище.

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

Ось дзеркало стійкого до linux-сховища kernel.org на GitHub, який може бути простішим для пошуку списків комісій та різним для вирішення конфлікту. Рекомендую спершу перейти до переліку списків фіксованих файлів та знайти локальну проблему, щоб переглянути оригінальний розріз, щоб порівняти її з вашим.

Приклад URL: //github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

Ви також можете зробити це за допомогою командного рядка:

 git log .. git show 

Вирішення резолюцій стосується всього контексту. Завжди потрібно зробити так, щоб ваш остаточний розріз збігався з потоком, виконавши наступні команди у двох окремих вікнах:

 git diff HEAD git diff v $ (зробити kernelversion) .. $ (тег git --sort = -taggerdate -lv $ (зробити kernelversion | cut -d. -f 1, 2) * | head -n1) 

Увімкнути повторне оновлення

У Git є функція під назвою rerere (означає повторне використання записаної роздільної здатності), це означає, що коли він виявить конфлікт, він запише, як ви його вирішили, щоб потім можна було повторно використовувати його. Це особливо корисно як для хронічних ребастерів, так і для злиття та збору вишні, оскільки вам просто потрібно буде запустити git add. && git - продовжуйте під час повторного підключення висхідного потоку, оскільки конфлікт буде вирішений тим, як ви його попередньо вирішили.

Це можна ввімкнути, виконавши таку команду у вашому репо ядрі:

 git config rerere.enabled true 

Як git bisect при запуску в компілятор або помилку виконання

Зважаючи на те, що ви будете додавати значну кількість комітетів, вам дуже можливо ввести помилку компілятора або виконання. Замість того, щоб просто здаватися, ви можете використовувати вбудований інструмент біт-бітів git, щоб з’ясувати першопричину проблеми! В ідеалі, ви будете створювати та прошивати кожну версію ядра, додаючи її, так що розбивання знадобиться менше часу, якщо потрібно, але ви можете розділити 5000 комісій без жодних проблем.

Що робитиме git bisect - це взяти діапазон комітетів, звідки виникла проблема, до якої її не було, а потім починайте вдвічі зменшити діапазон фіксування, що дозволить вам скласти і протестувати і повідомити, чи це добре чи ні . Це буде тривати до тих пір, поки не виплатить комісію, яка спричинила вашу проблему. У цей момент ви можете або виправити його, або повернути його назад.

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

ПРИМІТКА. Злиттям потрібно буде тимчасово запустити git rebase -i, щоб застосувати всі виправлення до своєї гілки для належного розбиття бірок, оскільки бісекція з об'єднаннями на місці часто разів перевіряє на верхні комікси, що означає, що у вас немає жодного конкретного зобов’язання Android. Я можу детальніше розібратися в цьому питанні на прохання, але довіряйте, це потрібно. Визначивши проблему, ви можете повернути або відновити її знову в об'єднанні.

НЕ скидайте оновлення за течією

Багато нових розробників спокушаються це зробити, оскільки це "чистіше" і "простіше" в управлінні. Це жахливо з кількох причин:

• Авторство втрачено. Інші розробники недобросовісно обмежують свою кредитну діяльність.
• Розбиття неможливо. Якщо ви скріповуєте серію комітетів, і щось є проблемою в цій серії, неможливо сказати, яка комісія викликала проблему в сквоші.
• Майбутні вишні вибирати важче. Якщо вам потрібно перезавантажити серію, що склалася, важко / неможливо сказати, звідки виникає конфлікт.

Підпишіться на список розсилки Linux Kernel для своєчасного оновлення

Щоб отримувати сповіщення щоразу, коли з'являється оновлення вище, підпишіться на список linux-ядро-оголошення. Це дозволить вам отримувати електронний лист щоразу, коли виходить нове ядро, щоб ви могли оновити та натиснути якнайшвидше.