Как да актуализирате Android Kernel до най-новата Linux Stable

Разкрихме ръководства за ядрата на Android, като „Как да изградим персонализирано ядро“ и „Най-добри персонализирани ядра за Android“, но днес ще ви покажем как да прехвърлите ядрото си спрямо най-новата стабилна Linux.

Моля, знайте, че това са разширени неща - ако никога досега не сте компилирали ядро, трябва да следвате ръководството „Как да изградим персонализирано ядро“, свързано по-горе, и това ръководство ще включва избор на череши и обединяване от най-новите Linux- стабилно ядро ​​с вашето ядро ​​Android, преди да го компилирате.

Обновяването на вашето Android ядро ​​до най-новата стабилна Linux има много положителни предимства, като например да сте в крак с най-новите ангажименти за сигурност и грешки - ще обясним някои от плюсовете и минусите по-късно в това ръководство.

Какво е Linux-Stable ядро?

Стабилна за Linux, както името подсказва, е стабилната ръка на ядрото на Linux. Другата ръка е известна като "главна линия", която е основният клон . Цялата разработка на ядрото на Linux се случва в основната линия и обикновено следва този процес:

1. Линус Торвалдс ще вземе куп лепенки от поддръжниците си в продължение на две седмици.
2. След тези две седмици той пуска ядро ​​rc1 (напр. 4.14-rc1).
3. За всяка седмица през следващите 6-8 седмици той ще пусне още едно RC (например 4.14-rc2, 4.14-rc3 и т.н.) ядро, което съдържа САМО корекции на грешки и регресия.
4. След като бъде счетена за стабилна, тя ще бъде пусната като tarball за изтегляне на 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), поддържан от Ben Hutchings
• 3.2 (LTS), поддържан от Ben Hutchings

Какви са предимствата от актуализиране на моето 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 (най-нов маркер по течението), това са следните числа за комитите на тези системи:

 ~ / ядра / стабилен за Linux (главен) $ git log --format =% h v4.4.78..v4.4.121 | wc -l2285 ~ / ядра / linux-стабилен (главен) $ git log --format =% h v4.4.78..v4.4.121 арка / ръка | wc -l58 ~ / ядра / linux-стабилен (главен) $ git log --format =% h v4.4.78..v4.4.121 арка / arm64 | wc -l22 ~ / ядра / linux-стабилен (главен) $ 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 blame, няма да ви каже директно.
• Презаписът е труден, тъй като не можете да преобразувате отново сливане, той ще предложи да изберете всички череди поотделно. Не бива обаче да се презаписва често, вместо да използвате git revert и git merge, когато е възможно.

Бих препоръчал да направите избор на череша, за да откриете първоначалните проблеми в конфликтите, да направите сливане, след което да възстановите проблема, след което да се актуализира, така че актуализирането да е по-лесно (тъй като сливането е по-бързо след актуализиране).

Добавете ангажиментите към източника си, по една версия по едно

Най-важната част от този процес е една версия по част. МОЖЕ да има проблемен кръпка във вашата серия по течението, което може да причини проблем със зареждането или да счупи нещо като звук или зареждане (обяснено в раздела за съвети и трикове). Правенето на инкрементални промени на версиите е важно поради тази причина, по-лесно е да намерите проблем в 50 реда, отколкото над 2000 поръчки за някои версии. Бих препоръчал да извършите пълно сливане само след като знаете за всички ангажименти и разрешаване на конфликти.

Бране на череши

Формат:

 git cherry-pick .. 

Пример:

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

сливам

Формат:

 git сливане 

Пример:

git merge v3.10.74

Препоръчвам да следите конфликтите в обединенията чрез премахване на # маркерите.

Как да разрешим конфликтите

Не можем да дадем стъпка по стъпка ръководство за разрешаване на всеки един конфликт, тъй като включва добро познаване на езика на C, но ето няколко подсказки.

Ако се обединявате, разберете какъв ангажимент причинява конфликта. Можете да направите това по два начина:

1. git log -pv $ (направи kernelversion) .. за да получите промените между текущата и най-новата версия от upstream. Флагът -p ще ви даде промените, направени от всеки ангажимент, за да можете да ги видите.
2. Изпълнете git blame във файла, за да получите хешовете на всеки ангажимент в района. След това можете да стартирате git show –format = fuller, за да видите дали заглавието е от mainline / stable, Google или CodeAurora.

• Разберете дали вече имате ангажимента. Някои доставчици като Google или CAF ще се опитат да потърсят нагоре по течението на критични грешки, като поправка на Мръсни COW, и техните задръствания могат да противоречат на тези нагоре. Можете да стартирате git log –grep = ”” и да видите дали той връща нещо. Ако това стане, можете да пропуснете ангажимента (ако черешово избиране с помощта на git reset –hard && git cherry-pick – продължаване) или да пренебрегнете конфликтите (премахнете <<<<< >>>>>).
• Отбележете дали е имало резерв, който обърква разделителната способност. Google и CAF обичат да подкрепят определени пластири, които стабилните не биха могли. Stable често ще трябва да адаптира разделителната способност на основния ангажимент към абсцеса на определени кръпки, които Google избира да подкрепи. Можете да разгледате ангажимента на основната линия, като стартирате git show (хешът на главната линия ще бъде наличен в съобщението за ангажиране на стабилния ангажимент). Ако има спор, който го обърквате, можете или да отхвърлите промените, или можете да използвате основната версия (което обикновено ще трябва да направите).
• Прочетете какво се опитва да извърши комитът и вижте дали проблемът вече е отстранен. Понякога CAF може да поправи грешка, независима от upstream, което означава, че можете или да презапишете тяхното поправяне за upstream или да го изхвърлите, като по-горе.

В противен случай може просто да е резултат от добавяне на 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 tag --sort = -taggerdate -lv $ (направи kernelversion | cut -d. -f 1, 2) * | head -n1) 

Активиране на повторно

Git има функция, наречена rerere (означава Reuse Recorded Resolution), което означава, че когато открие конфликт, ще запише как сте го разрешили, за да можете да го използвате повторно по-късно. Това е особено полезно както за хронични реставъри, така и за сливане и бране на череши, тъй като просто ще трябва да стартирате git add. && git - продължете, когато пренареждате връзката нагоре по течението, тъй като конфликтът ще бъде решен как сте го разрешили преди.

Тя може да бъде активирана чрез стартиране на следната команда във вашето ядро ​​репо:

 git config rerere.enabled true 

Как да git bisect при стартиране на компилатор или грешка по време на изпълнение

Като се има предвид, че ще добавяте значителен брой ангажименти, е много възможно да въведете компилатор или грешка по време на изпълнение. Вместо само да се откажете, можете да използвате вградения инструмент на git за бисект, за да разберете първопричината за проблема! В идеалния случай, вие ще изграждате и мигате всяка отделна версия на ядрото, докато я добавите, така че разделянето на файлове ще отнеме по-малко време, ако е необходимо, но можете да разделяте 5000 комисиона без проблеми.

Това, което ще прави git bisect, е да предприемете набор от ангажименти, откъдето е налице проблемът до мястото, където не е имало, и след това започнете да намалите наполовина обхвата на ангажименти, което ви позволява да изградите и тествате и да го уведомите дали е добър или не, Тя ще продължи това, докато не изплюе ангажимента, причиняващ проблема ви. В този момент можете да го поправите или да го върнете.

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

ЗАБЕЛЕЖКА: Сливанията ще трябва временно да стартират git rebase -i, за да приложат всички кръпки към вашия клон за правилно разделяне на biseiting, тъй като разделянето със сливанията на място често пъти проверява на връзките нагоре, което означава, че нямате нито една от специфичните ангажименти за Android. Мога да вляза в по-голяма дълбочина относно това при поискване, но повярвайте ми, необходимо е. След като идентифицирате проблемния ангажимент, можете да го върнете или възстановите отново в сливането.

НЕ мачкайте актуализации

Много нови разработчици се изкушават да направят това, тъй като е "по-чисто" и "по-лесно" за управление. Това е ужасно поради няколко причини:

• Авторът е загубен. Несправедливо е други разработчици да имат кредити за работата си.
• Разделянето е невъзможно. Ако съкратите поредица от ангажименти и нещо е проблем в тази серия, е невъзможно да се каже кои ангажименти са предизвикали проблем в скуош.
• Бъдещите череши са по-трудни. Ако имате нужда от повторно базиране с нарязана серия, е трудно / невъзможно да се каже откъде произтича конфликт.

Абонирайте се за пощенския списък на Linux Kernel за навременни актуализации

За да получавате известия винаги, когато има актуализация по течението, абонирайте се за списъка на linux-kernel-съобщение. Това ще ви позволи да получавате имейл всеки път, когато се появи ново ядро, за да можете да актуализирате и да натискате възможно най-бързо.