Jak zaktualizować jądro Androida do najnowszej wersji stabilnej systemu 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

Najbardziej czasochłonną częścią jest wstępne wychowanie; kiedy jesteś już na bieżąco, nie trzeba w ogóle czasu, aby dołączyć do nowej wersji, która zwykle zawiera nie więcej niż 100 zatwierdzeń. Korzyści, jakie to przynosi (większa stabilność i lepsze bezpieczeństwo dla użytkowników), powinny jednak wymagać tego procesu.

Jak scalić stabilne jądro Linuksa z jądrem Androida

Najpierw musisz dowiedzieć się, jaka wersja jądra działa na Twoim urządzeniu z Androidem.

Choć wydaje się to trywialne, konieczne jest, aby wiedzieć, od czego zacząć. Uruchom następujące polecenie w drzewie jądra:

zrobić kernelversion

Powróci do używanej wersji. Pierwsze dwie liczby posłużą do określenia gałęzi, której potrzebujesz (np. Linux-4.4.y dla dowolnego jądra 4.4), a ostatnia liczba zostanie użyta do określenia wersji, której potrzebujesz, aby rozpocząć łączenie (np. Jeśli używasz 4.4 .21, nastąpi scalenie 4.4.22).

Pobierz najnowsze źródło jądra z kernel.org

kernel.org zawiera najnowsze źródła jądra w repozytorium stabilne pod Linuksem . U dołu tej strony będą znajdować się trzy linki pobierania. Z mojego doświadczenia wynika, że ​​lustro Google jest najszybsze, ale wyniki mogą się różnić. Uruchom następujące polecenia:

git remote dodaj linux-stable https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit pobierz linux-stable

Zdecyduj, czy chcesz scalić całe jądro, czy wybierz najlepsze zmiany

Następnie musisz wybrać, czy chcesz scalić zatwierdzenia, czy wybrać najlepszy wybór. Oto zalety i wady każdego z nich i kiedy możesz je chcieć.

UWAGA: Jeśli twoje źródło jądra jest w formie tarballa, najprawdopodobniej będziesz musiał wybierać spośród najlepszych, w przeciwnym razie otrzymasz tysiące konfliktów plików, ponieważ git wypełnia historię wyłącznie na podstawie danych źródłowych, a nie tego, co zmienił OEM lub CAF. Po prostu przejdź do kroku 4.

Zbieranie wiśni:

Plusy:

• Łatwiej rozwiązywać konflikty, ponieważ dokładnie wiesz, jaki konflikt powoduje problem.
• Łatwiejsze do zmiany bazy, ponieważ każde zatwierdzenie jest niezależne.
• Łatwiej jest przeciąć, jeśli napotkasz problemy

Cons:

• Trwa to dłużej, ponieważ każde zatwierdzenie musi być wybrane indywidualnie.
• Nieco trudniej jest stwierdzić, czy na pierwszy rzut oka zatwierdzenie pochodzi z górnego źródła

Iść

Plusy :

• Jest to szybsze, ponieważ nie musisz czekać na połączenie wszystkich czystych poprawek.
• Łatwiej jest zobaczyć, kiedy zatwierdzenie pochodzi z zewnętrznego źródła, ponieważ nie będziesz zatwierdzającym, tylko jego opiekun.

Cons:

• Rozwiązywanie konfliktów może być nieco trudniejsze, ponieważ będziesz musiał sprawdzić, które zatwierdzenie powoduje konflikt za pomocą git log / git blame, nie powie ci bezpośrednio.
• Rebasing jest trudny, ponieważ nie można zmienić bazy scalenia, ponieważ umożliwia indywidualne wybranie wszystkich zatwierdzeń. Jednak nie powinieneś często zmieniać bazy, zamiast tego używaj git revert i git merge, jeśli to możliwe.

Zalecałbym wykonanie najlepszego wyboru, aby na początku wykryć wszelkie konflikty problemowe, wykonać scalanie, a następnie cofnąć zatwierdzenie problemu, aby aktualizacja była łatwiejsza (ponieważ scalanie jest szybsze po zaktualizowaniu).

Dodaj zatwierdzenia do źródła, jedną wersję na raz

Najważniejszą częścią tego procesu jest jedna wersja na raz. MOŻE istnieć łatka problemowa w twojej serii upstream, która może spowodować problem z bootowaniem lub zepsuć coś takiego jak dźwięk lub ładowanie (wyjaśnione w sekcji porad i wskazówek). Z tego powodu robienie przyrostowych zmian wersji jest ważne. W przypadku niektórych wersji łatwiej jest znaleźć problem w 50 zatwierdzeniach niż przy 2000 zatwierdzeniach w górę. Zalecałbym wykonanie pełnego scalenia tylko wtedy, gdy znasz wszystkie zatwierdzone problemy i rozwiązania konfliktów.

Zbieranie wiśni

Format:

git cherry-pick ..

Przykład:

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

Iść

Format:

połącz się

Przykład:

git merge v3.10.74

Zalecam śledzenie konfliktów w zatwierdzeniach scalających, usuwając znaczniki #.

Jak rozwiązywać konflikty

Nie możemy podać przewodnika krok po kroku, jak rozwiązać każdy konflikt, ponieważ wymaga to dobrej znajomości języka C, ale oto kilka wskazówek.

Jeśli scalasz, dowiedz się, jakie zatwierdzenie powoduje konflikt. Możesz to zrobić na dwa sposoby:

1. git log -p v $ (make kernelversion) .. aby pobrać zmiany między bieżącą wersją a najnowszą z nadawcy. Flaga -p poda zmiany wprowadzone przez każde zatwierdzenie, abyś mógł je zobaczyć.
2. Uruchom git blame na pliku, aby uzyskać skróty każdego zatwierdzenia w obszarze. Następnie możesz uruchomić git show –format = fuller, aby sprawdzić, czy committer pochodzi z mainline / stable, Google lub CodeAurora.

• Dowiedz się, czy masz już zatwierdzenie. Niektórzy dostawcy, tacy jak Google lub CAF, będą próbowali szukać krytycznych błędów, takich jak poprawka Dirty COW, i ich backporty mogą kolidować z wcześniejszymi. Możesz uruchomić git log –grep = ”” i sprawdzić, czy coś zwróci. Jeśli tak, możesz pominąć zatwierdzenie (jeśli wybrałeś za pomocą git reset –hard && git cherry-pick –continue) lub zignorować konflikty (usunąć<<<<<>>>>>).
• Dowiedz się, czy wystąpił backport, który psuje rozdzielczość. Google i CAF chcą wspierać pewne poprawki, których stabilna nie zrobiłaby. Wersja stabilna często będzie musiała dostosować rozdzielczość zobowiązania głównego do braku pewnych poprawek, które Google decyduje się na backport. Możesz spojrzeć na zatwierdzenie mainline, uruchamiając git show (hash mainline będzie dostępny w komunikacie zatwierdzenia stabilnego zatwierdzenia). Jeśli istnieje backport, który go psuje, możesz odrzucić zmiany lub użyć wersji głównej (co zwykle będziesz musiał zrobić).
• Przeczytaj, co próbuje zrobić commit i zobacz, czy problem został już rozwiązany. Czasami CAF może naprawić błąd niezależnie od źródła, co oznacza, że ​​możesz albo nadpisać ich poprawkę dla autorów, albo odrzucić, jak powyżej.

W przeciwnym razie może to być po prostu wynikiem dodania CAF / Google / OEM, w takim przypadku wystarczy przetasować kilka rzeczy.

Tutaj jest lustro repozytorium stabilnego linux kernel.org na GitHubie, co może być łatwiejsze do wyszukiwania list zatwierdzeń i różnic w celu rozwiązania konfliktów. Zalecam najpierw przejść do widoku listy zatwierdzeń i zlokalizować zatwierdzenie powodujące problem, aby zobaczyć oryginalny plik diff i porównać go z twoim.

Przykładowy adres URL: https://github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

Możesz to również zrobić za pomocą wiersza poleceń:

git log .. git show

Rozwiązywanie rezolucji dotyczy kontekstu. To, co powinieneś ZAWSZE robić, to upewnić się, że ostateczne różnice są zgodne z tymi nadrzędnymi, uruchamiając następujące polecenia w dwóch osobnych oknach:

git diff HEAD git diff v $ (make kernelversion) .. $ (tag git --sort = -taggerdate -l v $ (make kernelversion | cut -d. -f 1,2) * | head -n1)

Włącz rerere

Git ma funkcję o nazwie rerere (skrót od Reuse Recorded Resolution), co oznacza, że ​​gdy wykryje konflikt, zapisze, jak go rozwiązałeś, aby można było go później użyć ponownie. Jest to szczególnie przydatne zarówno dla chronicznych rebaserów z łączeniem, jak i wybieraniem wiśni, ponieważ wystarczy uruchomić git add. && git - kontynuuj podczas ponownego wykonywania wywołania nadrzędnego, ponieważ konflikt zostanie rozwiązany tak, jak rozwiązałeś go wcześniej.

Można go włączyć, uruchamiając następujące polecenie w repozytorium jądra:

git config rerere.enabled true

Jak przejść do połowy podczas uruchamiania kompilatora lub błędu czasu wykonania

Biorąc pod uwagę, że będziesz dodawać sporą liczbę zatwierdzeń, jest bardzo możliwe, że wprowadzisz błąd kompilatora lub czasu wykonania. Zamiast po prostu się poddawać, możesz użyć wbudowanego narzędzia git do połowy, aby znaleźć główną przyczynę problemu! Idealnie byłoby, gdybyś budował i flashował każdą wersję jądra, gdy ją dodasz, więc dzielenie na dwie części zajmie mniej czasu, jeśli zajdzie taka potrzeba, ale możesz podzielić na pół 5000 zatwierdzeń bez żadnych problemów.

To, co zrobi git bisect, to pobranie szeregu zatwierdzeń, od miejsca, w którym problem jest obecny, do miejsca, w którym go nie było, a następnie rozpoczęcie dzielenia zakresu zatwierdzeń o połowę, co pozwoli ci zbudować i przetestować i dać znać, czy jest dobry, czy nie . Będzie to kontynuować, dopóki nie wypluje zmiany powodującej problem. W tym momencie możesz to naprawić lub przywrócić.

1. Rozpocznij dzielenie na dwie części: git bisect start
2. Oznacz bieżącą wersję jako złą: git bisect bad
3. Oznacz wersję jako dobrą: git bisect good
4. Twórz z nową wersją
5. Na podstawie wyniku (czy problem występuje, czy nie), powiedz git: git bisect good OR git bisect bad
6. Wypłucz i powtarzaj kroki 4-5, aż problem zostanie znaleziony!
7. Przywróć lub napraw zatwierdzenie problemu.

UWAGA: Fuzje będą wymagały tymczasowego uruchomienia git rebase -i, aby zastosować wszystkie łaty do swojej gałęzi w celu poprawnego podzielenia na dwie części, ponieważ dzielenie na dwie części z wprowadzonymi scaleniami często powoduje wyewidencjonowanie do zatwierdzeń nadrzędnych, co oznacza, że ​​nie masz żadnych zatwierdzeń specyficznych dla Androida. Na życzenie mogę pogłębić tę kwestię, ale zaufaj mi, jest to potrzebne. Po zidentyfikowaniu zatwierdzania problemu można go przywrócić lub ponownie umieścić w scalaniu.

NIE blokuj aktualizacji zewnętrznych

Wielu nowych programistów ma pokusę, aby to zrobić, ponieważ jest to „czystsze” i „łatwiejsze” w zarządzaniu. To straszne z kilku powodów:

• Utracono autorstwo. Zastrzeganie sobie kredytu za ich pracę jest niesprawiedliwe dla innych programistów.
• Rozdzielanie jest niemożliwe. Jeśli zmiażdżysz serię zatwierdzeń i coś jest problemem w tej serii, nie można stwierdzić, które zmiany spowodowały problem w squashu.
• Przyszłe zrywki są trudniejsze. Jeśli musisz zmienić bazę za pomocą zgniecionej serii, trudno / niemożliwe jest powiedzieć, skąd wynika konflikt.

Zapisz się na listę mailingową Linux Kernel, aby otrzymywać aktualne aktualizacje

Aby otrzymywać powiadomienia o każdej aktualizacji nadrzędnej, zasubskrybuj lista linux-kernel-announce . Umożliwi to otrzymywanie wiadomości e-mail za każdym razem, gdy zostanie wydane nowe jądro, dzięki czemu będziesz mógł jak najszybciej zaktualizować i wysłać.