Android 커널을 최신 Linux 안정으로 업데이트하는 방법

우리는“커스텀 커널을 구축하는 방법”과“Android를위한 최고의 커스텀 커널”과 같은 안드로이드 커널에 대한 가이드를 다루었지만, 오늘은 최신 Linux 마진에 대비하여 커널을 업스트림하는 방법을 보여줄 것입니다.

이전에 커널을 컴파일 한 적이없는 경우 위에 링크 된 "사용자 정의 커널을 작성하는 방법"안내서를 따라야합니다.이 안내서에는 최신 Linux- 컴파일하기 전에 안드로이드 커널과 안정적인 커널.

Android 커널을 최신 Linux 마구간으로 업스트림하면 최신 보안 커밋 및 버그 수정으로 최신 상태를 유지하는 등 많은 긍정적 인 이점이 있습니다.이 가이드의 뒷부분에서 몇 가지 장단점을 설명합니다.

Linux-Stable 커널이란 무엇입니까?

Linux-stable은 이름에서 알 수 있듯이 Linux 커널의 안정적인 기능입니다. 다른 팔은 마스터 지점 인 "mainline"으로 알려져 있습니다. 모든 Linux 커널 개발은 메인 라인에서 이루어지며 일반적으로이 프로세스를 따릅니다.

  1. Linus Torvalds는 2 주 동안 관리자로부터 패치를받습니다.
  2. 이 2 주 후 rc1 (예 : 4.14-rc1) 커널을 릴리스합니다.
  3. 다음 6-8 주 동안 매주마다 버그와 회귀 수정 만 포함하는 다른 RC (예 : 4.14-rc2, 4.14-rc3 등) 커널을 릴리스합니다.
  4. 안정된 것으로 판단되면 org에서 다운로드 할 수있는 tarball로 릴리스됩니다 (예 : 4.14).

LTS 커널이란 무엇입니까?

매년 Greg는 하나의 커널을 선택하여 2 년 (LTS) 또는 6 년 (확장 LTS) 동안 유지합니다. 이들은 안드로이드 폰이나 다른 IOT 장치와 같이 안정성이 필요한 제품을 갖도록 설계되었습니다. 프로세스는 위와 동일하며 더 오랜 시간 동안 발생합니다. 현재 6 개의 LTS 커널이 있습니다 (kernel.org 릴리스 페이지에서 항상 볼 수 있음).

  • 4.14 (LTS), Greg Kroah-Hartman이 유지 보수
  • 4.9 (LTS), Greg Kroah-Hartman이 유지 보수
  • 4.4 (eLTS), Greg Kroah-Hartman이 유지 보수
  • 4.1 (LTS), Sasha Levin이 유지 보수
  • Ben Hutchings가 관리하는 3.16 (LTS)
  • 3.2 (LTS), Ben Hutchings가 유지 보수

Android 커널을 Linux Stable로 업스트림하면 어떤 이점이 있습니까?

중요한 취약점이 공개 / 수정 될 때, 안정적인 커널이 가장 먼저 노출됩니다. 따라서 Android 커널은 공격, 보안 결함 및 일반적인 버그에 대해 훨씬 안전합니다.

리눅스 마구간에는 안드로이드 기기가 사용하지 않는 많은 드라이버에 대한 수정 사항이 포함되어 있습니다.

"주로"정의하는 방법에 따라 예 및 아니요. Linux 커널에는 Android 시스템에서 사용되지 않는 많은 코드가 포함될 수 있지만 새 버전을 병합 할 때 해당 파일과 충돌이 발생하지는 않습니다. Ubuntu 또는 Mint와 같은 가장 일반적인 Linux 배포판조차도 커널의 모든 부분을 실제로 구축하는 사람 은 거의 없습니다 . 그렇다고 실행하는 드라이버에 대한 수정 프로그램이 있기 때문에 이러한 수정 사항을 사용해서는 안된다는 의미는 아닙니다. 가장 일반적인 Android 아키텍처 및 파일 시스템 인 arm / arm64 및 ext4를 예로들 수 있습니다. 4.4.78 (최신 Oreo CAF 태그 버전)에서 4.4.121 (최신 업스트림 태그)까지 4.4에서 해당 시스템의 커밋에 대한 다음 번호는 다음과 같습니다.

 ~ / kernels / linux-stable (마스터) $ git log --format = % h v4.4.78..v4.4.121 | wc -l2285 ~ / kernels / linux-stable (마스터) $ git log --format = % h v4.4.78..v4.4.121 arch / arm | wc -l58 ~ / kernels / linux-stable (마스터) $ git log --format = % h v4.4.78..v4.4.121 arch / arm64 | wc -l22 ~ / kernels / linux-stable (마스터) $ git log --format = % h v4.4.78..v4.4.121 fs / ext4 | 화장실 -l18 

가장 시간이 많이 걸리는 부분은 초기 시작입니다. 일단 최신 상태가되면 일반적으로 100 개 이하의 커밋을 포함하는 새로운 릴리스로 병합하는 데 시간이 전혀 걸리지 않습니다. 이로 인한 이점 (사용자의 안정성과 보안 향상)이이 프로세스를 필요로합니다.

Linux 안정적인 커널을 Android 커널로 병합하는 방법

먼저 안드로이드 장치가 어떤 커널 버전을 실행하고 있는지 알아 내야합니다.

이처럼 사소한 것처럼, 어디에서 시작해야하는지 알아야합니다. 커널 트리에서 다음 명령을 실행하십시오.

 커널 버전을 만들다 

현재 버전을 다시 반환합니다. 처음 두 숫자는 필요한 분기 (예 : 4.4 커널의 경우 linux-4.4.y)를 파악하는 데 사용되며 마지막 숫자는 병합을 시작해야하는 버전을 결정하는 데 사용됩니다 (예 : 4.4에있는 경우) .21, 다음 4.4.22를 병합합니다).

kernel.org에서 최신 커널 소스를 가져옵니다

kernel.org는 linux-stable 리포지토리에 최신 커널 소스를 저장합니다. 페이지 하단에는 3 개의 페치 링크가 있습니다. 내 경험상 Google 미러는 가장 빠른 경향이 있지만 결과는 다를 수 있습니다. 다음 명령을 실행하십시오.

 git remote add linux-stable //kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable.gitgit 리눅스 안정을 가져옵니다 

전체 커널을 병합할지 또는 커밋을 체리 픽 선택할지 결정

다음으로 커밋 또는 체리 픽을 병합 할 것인지 선택해야합니다. 여기 각각의 장단점이 있습니다.

참고 : 커널 소스가 tarball 형식 인 경우 체리 픽 선택이 필요할 것입니다. 그렇지 않으면 git이 OEM 또는 CAF가 아닌 업스트림을 기반으로 기록을 채우므로 수천 개의 파일 충돌이 발생합니다. 변경되었습니다. 4 단계로 건너 뛰십시오.

체리 따기 :

장점 :

  • 어떤 충돌이 문제를 일으키는 지 정확히 알면 충돌을 쉽게 해결할 수 있습니다.
  • 각 커밋이 자체적으로 진행되므로 더 쉽게 리베이스 할 수 있습니다.
  • 문제가 발생하면 쉽게 이등분

단점 :

  • 각 커밋을 개별적으로 선택해야하므로 시간이 더 걸립니다.
  • 커밋이 첫눈에 업스트림에서 온 것인지 알기가 조금 더 어렵습니다.

병합

찬성 :

  • 모든 클린 패치가 병합 될 때까지 기다릴 필요가 없으므로 더 빠릅니다.
  • 커미터가 아니기 때문에 커밋이 업스트림에서 언제 발생했는지 쉽게 알 수 있습니다. 업스트림 관리자가됩니다.

단점 :

  • git log / git blame을 사용하여 충돌을 일으키는 커밋을 찾아야하기 때문에 충돌을 해결하는 것이 조금 더 어려울 수 있습니다. 직접 말해주지는 않습니다.
  • 리베이스는 병합을 리베이스 할 수 없으므로 어려우며 모든 커밋을 개별적으로 체리 선택합니다. 그러나 가능한 경우 git revert 및 git merge를 사용하는 대신 자주 rebasing해서는 안됩니다.

체리 픽 선택을 수행하여 처음에 문제 충돌을 파악하고 병합을 수행 한 다음 문제 커밋을 되 돌리면 업데이트가 더 쉬워집니다 (업데이트 후 병합이 더 빠름).

한 번에 한 버전 씩 소스에 커밋 추가

이 프로세스에서 가장 중요한 부분은 한 번에 하나의 버전입니다. 업스트림 시리즈에 문제 패치가있을 수 있습니다. 부팅에 문제가 있거나 소리 나 충전과 같은 문제가 발생할 수 있습니다 (팁 및 요령 섹션에서 설명). 이러한 이유로 증분 버전 변경을 수행하는 것이 중요합니다. 일부 버전의 경우 2000 이상의 커밋보다 50 개의 커밋에서 문제를 찾는 것이 더 쉽습니다. 모든 문제 커밋 및 충돌 해결을 알고 나면 전체 병합을 수행하는 것이 좋습니다.

체리 따기

체재:

 자식 체리 픽 .. 

예:

자식 체리 픽 v3.10.73..v3.10.74

병합

체재:

 자식 병합 

예:

자식 병합 v3.10.74

# 마커를 제거하여 병합 커밋의 충돌을 추적하는 것이 좋습니다.

충돌을 해결하는 방법

C 언어에 대한 지식이 풍부하기 때문에 모든 충돌 문제를 해결하기위한 단계별 가이드를 제공 할 수는 없지만 몇 가지 힌트가 있습니다.

병합하는 경우 어떤 커밋이 충돌을 일으키는 지 파악하십시오. 이 두 가지 방법 중 하나를 수행 할 수 있습니다.

  1. git log -pv $ (make kernelversion) .. 현재 버전과 최신 버전 사이의 변경 사항을 업스트림에서 가져옵니다. -p 플래그는 각 커밋에 의해 수행 된 변경 사항을 제공하므로 알 수 있습니다.
  2. 파일에서 git blame을 실행하여 해당 영역에서 각 커밋의 해시를 가져옵니다. 그런 다음 git show –format = fuller를 실행하여 커미터가 mainline / stable, Google 또는 CodeAurora에서 온 것인지 확인할 수 있습니다.
  • 커밋이 이미 있는지 확인하십시오. Google 또는 CAF와 같은 일부 공급 업체는 Dirty COW 수정과 같은 중요한 버그를 업스트림에서 찾으려고하며 백 포트가 업스트림과 충돌 할 수 있습니다. git log –grep =””를 실행하면 무엇이 반환되는지 확인할 수 있습니다. 그렇다면 커밋을 건너 뛰거나 (git reset –hard && git cherry-pick –continue를 사용하여 cherry-picking하는 경우) 충돌을 무시하거나 <<<<< >>>>>를 제거 할 수 있습니다.
  • 분해능을 방해하는 백 포트가 있는지 확인하십시오. Google과 CAF는 안정적이지 않은 특정 패치를 백 포트하려고합니다. Stable은 종종 Google이 백 포트하기로 선택한 특정 패치가 없도록 메인 라인 커밋의 해상도를 조정해야합니다. git show를 실행하여 메인 라인 커밋을 볼 수 있습니다 (메인 라인 해시는 안정적인 커밋의 커밋 메시지에서 사용할 수 있습니다). 백 포트가 엉망인 경우 변경 사항을 취소하거나 기본 버전 (일반적으로 수행해야하는 것)을 사용할 수 있습니다.
  • 커밋이 수행하려는 작업을 읽고 문제가 이미 수정되었는지 확인하십시오. 때때로 CAF는 업스트림과 독립적으로 버그를 수정할 수 있습니다. 즉, 위와 같이 업스트림에 대한 수정 사항을 덮어 쓰거나 버릴 수 있습니다.

그렇지 않으면 CAF / Google / OEM 추가의 결과 일 수 있습니다.이 경우 주변 환경을 섞어 야합니다.

다음은 GitHub의 linux-stable kernel.org 리포지토리의 미러입니다. 커밋 목록과 충돌 해결을 쉽게 찾을 수 있습니다. 먼저 커밋 목록보기로 이동하여 문제 커밋을 찾아서 원래 diff를 비교하여 확인하십시오.

URL 예 : //github.com/nathanchance/linux-stable/commits/linux-3.10.y/arch/arm64/mm/mmu.c

명령 행을 통해 수행 할 수도 있습니다.

 자식 로그 .. 자식 표시 

해결 방법은 모두 맥락에 관한 것입니다. 항상해야 할 일은 두 개의 별도 창에서 다음 명령을 실행하여 최종 diff가 업스트림과 일치하는지 확인하는 것입니다.

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

다시 사용

Git에는 rerere (Reuse Recorded Resolution의 약자)라는 기능이 있습니다. 즉, 충돌이 감지되면 해결 방법을 기록하여 나중에 재사용 할 수 있습니다. 이것은 git add를 실행하면되기 때문에 병합과 체리 피킹이 모두 포함 된 만성 리저버 모두에 특히 유용합니다. && git – 업스트림 가져 오기를 다시 실행할 때 계속 진행하여 충돌이 이전에 해결 된 방식으로 해결됩니다.

커널 저장소에서 다음 명령을 실행하여 활성화 할 수 있습니다.

 git config rerere.enabled true 

컴파일러 또는 런타임 오류가 발생할 때 이등분하는 방법

상당한 수의 커밋을 추가한다고 가정하면 컴파일러 또는 런타임 오류가 발생할 수 있습니다. 포기하지 않고 git의 내장 bisect 도구를 사용하여 문제의 근본 원인을 파악할 수 있습니다! 이상적으로는 커널을 추가 할 때마다 모든 단일 커널 버전을 빌드하고 플래시하므로 필요한 경우 bisecting은 시간이 덜 걸리지 만 문제없이 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를 일시적으로 실행하여 분기에 적절한 패치를 적용해야합니다. 즉, Android 전용 커밋이 없습니다. 나는 요청에 따라 이것에 대해 더 깊이 들어갈 수 있지만 나를 믿어 라. 문제 커밋을 식별 한 후에는 해당 커밋을 되돌 리거나 병합하여 병합 할 수 있습니다.

업스트림 업데이트를 스쿼시하지 마십시오

많은 새로운 개발자들이 관리하기에 "깨끗하고"더 쉬워 지도록 유혹하고 있습니다. 몇 가지 이유로 끔찍합니다.

  • 저작권이 손실되었습니다. 다른 개발자가 자신의 작업에 대한 신용을 빼앗기는 것은 불공평합니다.
  • 이등분은 불가능합니다. 일련의 커밋을 스쿼시하고 그 시리즈에서 문제가있는 경우 스쿼시에서 어떤 커밋이 문제의 원인인지 알 수 없습니다.
  • 미래의 체리 픽은 더 어렵다. 찌그러진 시리즈로 리베이스해야 할 경우 충돌의 원인을 파악하기가 어렵거나 불가능합니다.

시기 적절한 업데이트를 위해 Linux Kernel 메일 링리스트에 가입

업스트림 업데이트가있을 때마다 알림을 받으려면 linux-kernel-announce 목록을 구독하십시오. 이를 통해 새로운 커널이 출시 될 때마다 이메일을받을 수 있으므로 최대한 빨리 업데이트하고 푸시 할 수 있습니다.

재미있는 기사