Как да актуализирате вашето 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 | wc -l18

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

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

Първо трябва да разберете коя версия на ядрото работи на вашето устройство с Android.

Колкото и тривиално да изглежда това, необходимо е да знаете откъде трябва да започнете. Изпълнете следната команда във вашето дърво на ядрото:

направи kernelversion

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

Вземете най-новия източник на ядрото от kernel.org

kernel.org съхранява най - новия източник на ядрото в Linux-стабилното хранилище . В долната част на тази страница ще има три връзки за извличане. Според моя опит огледалото на Google е най-бързо, но резултатите ви може да се различават. Изпълнете следните команди:

git отдалечено добавяне на linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit извличане на linux-stable

Решете дали искате да обедините цялото ядро ​​или да изберете коммитите

След това ще трябва да изберете дали искате да обедините ангажиментите или Cherry-Pick. Ето плюсовете и минусите на всеки и кога може да искате да ги направите.

ЗАБЕЛЕЖКА: Ако вашият източник на ядрото е под формата на тарбол, най-вероятно ще трябва да избирате череши, в противен случай ще получите хиляди файлови конфликти, защото git попълва историята, базирана чисто на горната част, а не на това, което са променили OEM или CAF. Просто преминете към стъпка 4.

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

Професионалисти:

• По-лесно е да разрешавате конфликти, тъй като знаете точно какъв конфликт причинява проблем.
• По-лесно е да се пребазира, тъй като всеки фиксиране е сам по себе си.
• По-лесно се разделя на две, ако се сблъскате с проблеми

Минуси:

• Отнема повече време, тъй като всеки ангажимент трябва да бъде избран индивидуално.
• Малко по-трудно е да се разбере дали фиксирането е от горния поток на пръв поглед

Отивам

Професионалисти :

• По-бързо е, тъй като не е нужно да чакате всички чисти петна да се слеят.
• По-лесно е да видите кога фиксирането е от горната част на веригата, тъй като вие няма да бъдете ангажиращият, а поддържащият нагоре по веригата.

Минуси:

• Разрешаването на конфликти може да бъде малко по-трудно, тъй като ще трябва да потърсите кой ангажимент причинява конфликта, използвайки git log / git вината, няма директно да ви каже.
• Пребазирането е трудно, тъй като не можете да пребазирате сливането, той ще предложи да изберете всеки от ангажиментите поотделно. Не бива обаче да пребазирате често, вместо да използвате 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) .. за да получите промените между текущата версия и най-новата от upstream. Флагът -p ще ви даде промените, направени от всеки фиксиране, за да можете да видите.
2. Изпълнете git вината върху файла, за да получите хешовете на всеки ангажимент в областта. След това можете да стартирате git show –format = fuller, за да видите дали коммитът е от mainline / stable, Google или CodeAurora.

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

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

Ето го огледало на Linux-стабилното хранилище на kernel.org на GitHub, което може да бъде по-лесно за търсене на списъци с ангажименти и разлики за разрешаване на конфликти. Препоръчвам първо да отидете в изгледа на списъка на ангажименти и да откриете проблемния ангажимент, за да видите оригиналната разлика, за да я сравните с вашата.

Примерен URL адрес: https://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 $ (make kernelversion) .. $ (git tag --sort = -taggerdate -l v $ (make kernelversion | cut -d. -f 1,2) * | head -n1)

Активиране на повторното възстановяване

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

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

git config rerere.enabled true

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

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

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

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

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

НЕ смачквайте актуализации нагоре по веригата

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

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

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

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