GKI(Generic Kernel Image)

Android 일반 커널(ACK)은 모든 Android 제품 커널의 기반이 됩니다. 공급업체 및 기기 커널은 ACK의 다운스트림입니다. 공급업체는 커널 소스 코드를 수정하고 기기 드라이버를 추가하여 SoC 및 주변기기에 관한 지원을 추가합니다. 이러한 수정은 기기에서 실행되는 코드 중 최대 50%가 트리 외부 코드(업스트림 Linux 또는 AOSP 일반 커널 코드가 아님)일 정도로 광범위할 수 있습니다.

따라서 기기 커널은 다음으로 구성됩니다.

  • 업스트림: kernel.org의 Linux 커널
  • AOSP: AOSP 일반 커널의 추가 Android 관련 패치
  • 공급업체: 공급업체의 SoC 및 주변기기 사용 설정 및 최적화 패치
  • OEM/기기: 추가 기기 드라이버 및 맞춤설정

거의 모든 기기에는 맞춤 커널이 있습니다. 다음은 커널 조각화입니다.

Android 커널 계층 구조에 따른 조각화

그림 1. Android 커널 계층 구조에 따른 조각화

조각화 비용

커널 조각화는 Android 커뮤니티에 몇 가지 부정적인 영향을 줍니다.

보안 업데이트에 많은 작업이 필요함

Android 보안 게시판(ASB)에 인용된 보안 패치는 각 기기 커널로 백포팅되어야 합니다. 그러나 커널 조각화로 인해 보안 수정사항을 현장의 Android 기기에 전파하는 데 엄청난 비용이 듭니다.

LTS(Long Term Supported) 업데이트를 병합하기가 어려움

LTS(Long Term Supported) 버전에는 보안 수정사항 및 기타 중요한 버그 수정이 포함됩니다. LTS 버전을 최신 상태로 유지하는 것이 보안 수정사항을 제공하는 가장 효과적인 방법임이 입증되었습니다. Pixel 기기에서는 ASB에 보고된 커널 보안 문제의 90%가 최신 상태로 유지되는 기기에서 이미 수정된 것으로 확인되었습니다.

그러나 기기 커널의 모든 맞춤 수정으로 인해 LTS 수정사항을 기기 커널에 병합하는 것이 어렵습니다.

Android 플랫폼 출시 업그레이드 제약

조각화로 인해 커널 변경이 필요한 새로운 Android 기능을 현장의 기기에 추가하기 어려워질 수 있습니다. Android 프레임워크 코드는 최대 5개의 커널 버전이 지원되며 새 플랫폼 출시에 관한 커널 변경사항이 없다고 가정해야 합니다(Android 10은 3.18, 4.4, 4.9, 4.14 및 4.19 커널을 지원하며 일부 경우 이러한 커널은 2017년 Android 8 이후 새로운 기능으로 개선되지 않음).

커널 변경사항을 업스트림 Linux에 다시 제공하기 어려움

커널과 관련된 모든 변경사항에도 불구하고 대부분의 플래그십 기기에는 이미 18개월 이상된 커널 버전이 제공됩니다. 예를 들어 4.14 커널은 2017년 11월에 kernel.org에 의해 출시되었으며, 4.14 커널을 탑재한 최초의 Android 휴대전화는 2019년 봄에 출시되었습니다.

업스트림 커널 출시와 제품 간의 이러한 긴 지연으로 인해 Android 커뮤니티가 필요한 기능 및 드라이버를 업스트림 커널에 공급하기 어렵기 때문에 조각화 문제를 해결하기가 어렵습니다.

조각화 문제 해결: GKI(Generic Kernel Image)

GKI(Generic Kernel Image) 프로젝트는 코어 커널을 통합하고 SoC 및 보드 지원을 코어 커널에서 로더블 모듈로 이동하여 커널 조각화를 해결합니다. GKI 커널은 커널 모듈을 위한 안정적인 커널 모듈 인터페이스(KMI)를 제공하므로 모듈과 커널을 독립적으로 업데이트할 수 있습니다.

GKI:

  • ACK 소스에서 빌드됩니다.
  • 단일 커널 바이너리와 LTS 출시별 아키텍처당 관련 로더블 모듈입니다(현재 android11-5.4 및 android12-5.4용 arm64만 해당).
  • 관련 ACK에 대해 지원되는 모든 Android 플랫폼 출시에서 테스트됩니다. GKI 커널 버전의 전체 기간 동안 기능 지원 중단이 없습니다.
  • 지정된 LTS 내에 드라이버에 안정적인 KMI를 노출합니다.
  • SoC 또는 보드 관련 코드를 포함하지 않습니다.

GKI가 구현된 Android 기기는 다음과 같습니다.

GKI 아키텍처

그림 2. GKI 아키텍처

GKI는 Android 11 플랫폼 출시에서 v5.4 커널부터 시작하여 여러 단계로 출시되며, 변경사항이 다소 복잡합니다.

GKI 1.0 — GKI 호환성 요구사항

Android 11 플랫폼 출시의 경우 Treble 호환성을 위해서는 v5.4 커널을 실행하는 기기에 대한 GKI 테스트가 필요합니다.

GKI 호환성 테스트를 위한 파티션

그림 3. GKI 호환성 테스트를 위한 파티션

GKI 호환성은 기기가 GKI 부팅 이미지를 boot 파티션으로 플래시하고 system 파티션의 GSI 시스템 이미지를 플래시하여 설치된 GKI 커널 및 일반 시스템 이미지(GSI)를 사용해 VTS 및 CTS-on-GSI+GKI 테스트를 통과한다는 것을 의미합니다. 기기는 다양한 제품 커널과 함께 제공될 수 있으며 GKI에서 제공하지 않는 로더블 모듈을 사용할 수 있습니다. 그러나 제품 및 GKI 커널은 모두 동일한 vendor_boot 및 vendor 파티션에서 모듈을 로드해야 합니다. 따라서 모든 제품 커널에는 동일한 바이너리 커널 모듈 인터페이스(KMI)가 있어야 합니다. 공급업체는 GKI KMI와 호환 상태를 유지하는 동안에는 제품 커널용 KMI를 확장할 수 있습니다. GKI 1.0에서 공급업체 모듈을 언로드할 수 있어야 한다는 요구사항은 없습니다.

GKI 1.0 목표

  • 제품 커널이 GKI 커널로 대체될 때 VTS 또는 CTS에 회귀를 도입하지 않습니다.
  • OEM 및 공급업체에서 AOSP 일반 커널을 최신 상태로 유지해야 하는 커널 유지관리 부담을 줄입니다.
  • 기기가 새로운 Android 플랫폼 출시로 업그레이드되었는지 또는 새로 출시되었는지와 관계없이 핵심 Android 변경사항을 커널에 포함합니다.
  • Android 사용자 공간을 방해하지 않습니다.
  • 코어 커널에서 하드웨어 관련 구성요소를 로더블 모듈로 분리합니다.

GKI 2.0 - GKI 제품

커널 버전 v5.x(여기서 5.x는 2020년 말에 LTS로 선택된 커널) 이상을 사용하여 Android S(2021) 플랫폼 버전으로 출시되는 기기는 GKI 커널과 함께 제공되어야 합니다. 서명된 부팅 이미지는 LTS 및 중요한 버그 수정을 통해 정기적으로 제공되고 업데이트됩니다. KMI에 대한 바이너리 안정성이 유지되므로 공급업체 이미지를 변경하지 않고 이러한 부팅 이미지를 설치할 수 있습니다.

GKI 2.0 목표

  • GKI로 상당한 성능 회귀를 도입하지 않습니다.
  • OEM이 공급업체의 개입 없이 커널 보안 수정 및 버그 수정(LTS)을 제공할 수 있도록 합니다.
  • 기기의 주요 커널 버전을 업데이트(예: v5.x에서 v5.y로)하는 비용을 줄입니다.
  • 명확한 업그레이드 프로세스로 커널 버전을 업데이트하여 아키텍처당 하나의 GKI 커널 바이너리만 유지합니다.

GKI 설계

KMI 커널 분기

GKI 커널은 Android 일반 커널에 자세히 설명되어 있는 ACK KMI 커널 분기에서 빌드됩니다. KMI는 커널 버전 및 Android 플랫폼 출시에서 고유하게 식별되며, 분기 이름은 <androidRelease>-<kernel version>입니다. 예를 들어 Android 11용 5.4 KMI 커널 분기의 이름은 android11-5.4.입니다. Android S(커밋되지 않고 향후 새로운 분기 모델이 어떻게 진행될 것인지를 보여주기 위해서만 표시됨)의 경우 2개의 추가 KMI 커널인 android12-5.4와 2020년 말에 선언될 새로운 LTS 커널을 기반으로 하는 두 번째 커널이 있을 것으로 예상됩니다.

KMI 커널 계층 구조

그림 4는 5.x KMI 커널의 분기 계층 구조를 보여줍니다(여기서 5.x는 2020년 말에 LTS로 선택된 커널). android12-5.x는 Android S에 해당하는 KMI 커널이며 android13-5.x는 Android 13에 해당합니다(커밋되지 않고 향후 새로운 분기 모델이 어떻게 진행될 것인지를 보여주기 위해서만 표시됨).

5.x용 KMI 커널 계층 구조

그림 4. 5.x용 KMI 커널 계층 구조

그림 4와 같이 KMI 분기는 개발(dev), 안정화(stab) 및 고정(frozen)의 세 단계를 순환합니다. 이러한 단계는 Android 일반 커널에 자세히 설명되어 있습니다.

KMI 커널이 고정되면 안정적인 KMI에 영향을 주지 않고는 완화할 수 없는 심각한 보안 문제가 확인되지 않는 한 KMI 브레이킹 체인지가 허용되지 않습니다. 분기는 전체 기간 동안 고정된 상태로 유지됩니다.

기존 KMI가 손상되지 않는 한 버그 수정 및 파트너 기능은 고정된 분기에 허용될 수 있습니다. 현재 KMI를 구성하는 인터페이스가 영향을 받지 않는 한 KMI는 새로 내보낸 기호로 확장될 수 있습니다. 새 인터페이스는 KMI에 추가되면 즉시 안정화되며 향후 변경으로 인해 손상되지 않습니다.

예를 들어 다음과 같이 KMI 인터페이스에서 사용하는 구조에 필드를 추가하는 변경은 인터페이스 정의를 변경하기 때문에 허용되지 않습니다.

struct foo {
  int original_field1;
  int original_field2;
  int new_field; // Not allowed
};

int do_foo(struct foo &myarg)
{
  do_something(myarg);
}
EXPORT_SYMBOL_GPL(do_foo);

그러나 다음과 같이 새 함수를 추가하는 것은 괜찮습니다.

struct foo_ext {
  struct foo orig_foo;
  int new_field;
};

int do_foo2(struct foo_ext &myarg)
{
  do_something_else(myarg);
}
EXPORT_SYMBOL_GPL(do_foo2);

KMI 안정성

GKI 목표를 실현하기 위해서는 드라이버에 대해 안정적인 KMI를 유지하는 것이 중요합니다. GKI 커널은 바이너리 형식으로 빌드되고 제공되지만 공급업체 로더블 모듈은 별도의 트리에 빌드됩니다. 그 결과로 생성되는 GKI 커널 및 모듈은 함께 빌드된 것처럼 작동해야 합니다. GKI 호환성 테스트의 경우 커널이 포함된 부팅 이미지가 GKI 커널이 포함된 부팅 이미지로 대체되며, 공급업체 이미지의 로더블 모듈은 두 커널 중 하나와 함께 올바르게 작동해야 합니다.

KMI에는 커널의 기호가 모두 포함되어 있지 않거나 30,000개 이상의 내보낸 기호도 모두 포함되어 있지 않습니다. 대신 모듈에서 사용할 수 있는 기호는 커널 트리의 루트에 공개적으로 유지되는 기호 목록 파일 세트에 명시적으로 나열됩니다. 모든 기호 목록 파일에 있는 모든 기호의 공용체는 안정된 상태로 유지되는 KMI 기호 세트를 정의합니다. 기호 목록 파일의 예는 abi_gki_aarch64_db845c로, DragonBoard 845c에 필요한 기호를 선언합니다.

기호 목록에 나열된 기호와 관련 구조 및 정의만 KMI의 일부로 간주됩니다. 필요한 기호가 없다면 기호 목록에 변경사항을 게시할 수 있습니다. 새 인터페이스가 기호 목록에 있고 따라서 KMI 설명의 일부가 된 이후에 이 인터페이스는 안정적인 상태로 유지되므로 분기가 고정된 후 기호 목록에서 제거되거나 수정되어서는 안 됩니다.

각 KMI 커널 트리에는 고유한 기호 목록 세트가 있습니다. 서로 다른 KMI 커널 분기 간에 ABI 안정성을 제공하려고 시도하지 않습니다. 예를 들어 android11-5.4용 KMI와 android12-5.4용 KMI는 완전히 별개입니다.

일반적으로 Linux 커뮤니티는 메인라인 커널에 대한 커널 내 ABI 안정성 개념을 그다지 좋아하지 않습니다. 다양한 도구 모음, 구성 및 끊임없이 진화하는 Linux 메인라인 커널에도 불구하고 메인라인에서 안정적인 KMI를 유지하는 것은 불가능합니다. 그러나 고도로 제한된 GKI 환경에서는 가능합니다. 제약 조건은 다음과 같습니다.

  • KMI는 동일한 LTS 커널(예: android11-5.4) 내에서만 안정적입니다.
    • android-mainline에서는 KMI 안정성이 유지되지 않습니다.
  • AOSP에서 제공되고 해당 분기에 대해 정의된 특정 Clang 도구 모음만 커널 및 모듈 빌드에 사용됩니다.
  • 기호 목록에 지정된 대로 모듈에서 사용하는 것으로 알려진 기호만 안정성을 위해 모니터링되고 KMI 기호로 간주됩니다.
    • 결과적으로 모듈은 KMI 기호만 사용해야 합니다. 모듈이 KMI 기호가 아닌 기호를 요구하면 모듈 로드가 실패함으로써 강제 적용됩니다.
  • KMI 분기가 고정된 이후에는 다음을 비롯한 변경사항으로 인해 KMI가 손상되지 않습니다.
    • 구성 변경사항
    • 커널 코드 변경사항
    • 도구 모음 변경사항(업데이트 포함)

KMI 모니터링

ABI 모니터링 도구는 사전 제출 테스트 중에 KMI 안정성을 모니터링합니다. KMI를 손상하는 변경사항은 사전 제출 테스트에 실패하며 호환될 수 있도록 재작업해야 합니다. 이러한 도구는 파트너 및 일반 사용자가 빌드 프로세스에 통합하는 데 사용할 수 있습니다. Android 커널 팀은 이러한 도구를 사용하여 개발 중 그리고 LTS 출시 병합 시 KMI 손상을 찾습니다. LTS 병합 중에 KMI 손상을 감지하면 문제가 되는 패치를 제거하거나 호환될 수 있도록 패치를 리팩터링하여 KMI를 보존합니다.

기존 KMI 기호를 호환되지 않는 방식으로 수정하면 KMI가 손상된 것으로 간주합니다. 예를 들면 다음과 같습니다.

  • KMI 함수에 새 인수 추가
  • KMI 함수에서 사용하는 구조에 새 필드 추가
  • KMI 함수에서 사용하는 enum 값을 변경하는 새 enum 값 추가
  • KMI에 영향을 주는 데이터 멤버의 존재를 변경하는 구성 변경

새 기호를 추가한다고 해서 반드시 KMI가 손상되는 것은 아니지만 사용되는 새 기호를 기호 목록 및 ABI 표현에 추가해야 합니다. 그러지 않으면 KMI의 이 부분에 관한 이후의 변경사항이 인식되지 않습니다.

파트너는 ABI 모니터링 도구를 사용하여 제품 커널과 GKI 커널 간의 KMI를 비교하고 호환되는지 확인해야 합니다.

최신 android11-5.4 바이너리 GKI 커널은 ci.android.com(kernel_aarch64 빌드)에서 다운로드할 수 있습니다.

단일 컴파일러

컴파일러 변경으로 인해 ABI에 영향을 주는 내부 커널 데이터 구조 레이아웃이 변경될 수 있습니다. KMI를 안정적으로 유지하는 것이 중요하므로 GKI 커널을 빌드하는 데 사용되는 도구 모음은 공급업체 모듈을 빌드하는 데 사용되는 도구 모음과 완벽하게 호환되어야 합니다. GKI 커널은 AOSP에 포함된 LLVM 도구 모음으로 빌드되었습니다.

Android 10부터 모든 Android 커널은 LLVM 도구 모음으로 빌드되어야 합니다. GKI 사용 시 제품 커널 및 공급업체 모듈을 빌드하는 데 사용되는 LLVM 도구 모음은 AOSP의 LLVM 도구 모음과 동일한 ABI를 생성해야 하며, 파트너는 KMI가 GKI 커널과 호환되는지 확인해야 합니다.

Android 커널 빌드 문서에서는 참조 GKI 커널이 빌드되는 방식을 설명합니다. 특히 문서화된 절차에서는 커널을 빌드하는 데 올바른 도구 모음 및 구성이 사용되는지 확인합니다. 다운스트림 파트너는 도구 모음 또는 기타 빌드 시간 종속 항목으로 인한 비호환성을 방지하기 위해 최종 커널을 생성하는 데 동일한 도구를 사용하는 것이 좋습니다.

커널 구성

GKI 커널은 arch/arm64/configs/gki_defconfig를 사용하여 빌드됩니다. 이러한 구성은 KMI에 영향을 주므로 GKI 구성은 매우 신중하게 관리됩니다. 고정된 KMI 커널의 경우 KMI에 미치는 영향이 없는 경우에만 구성을 추가하거나 삭제할 수 있습니다.

GKI 커널은 다양한 기기 세트에서 실행되도록 구성해야 합니다. 따라서 GKI 커널에는 이러한 모든 기기에 필요한 모든 하위 시스템 및 옵션에 대한 지원이 내장되어 있어야 합니다. 여기에는 하드웨어를 사용 설정하는 데 사용되는 로더블 모듈은 포함되지 않습니다. 파트너는 개발(dev) 커널에 필요한 구성 변경을 요청해야 합니다.

부팅 변경사항

GKI와 공급업체 구성요소 간의 깔끔한 분리를 용이하게 하기 위해 boot 파티션에는 GKI 모듈이 있는 램디스크 및 커널을 비롯하여 일반적인 구성요소만 포함됩니다. 새 버전의 부팅 헤더(v3)가 GKI 아키텍처 규정 준수를 나타내도록 정의됩니다. 부팅 이미지의 GKI 버전은 Google에서 제공하며 GKI 호환성 테스트 시 공급업체의 부팅 이미지 버전을 대체합니다.

1단계 init, recovery 및 fastbootd용 램디스크는 부트로더에 의해 연결된 2개의 CPIO 아카이브로 구성된 initramfs 이미지입니다. 첫 번째 CPIO 아카이브는 새 vendor_boot 파티션에서 비롯됩니다. 두 번째 아카이브는 boot 파티션에서 비롯됩니다.

여기에서는 변경사항을 간략히 설명합니다. 자세한 내용은 공급업체 부팅 파티션을 참고하세요.

부팅 파티션

boot 파티션에는 일반적인 부팅 램디스크 부분의 헤더, 커널 및 CPIO 아카이브가 포함됩니다.

부팅 헤더 v3 boot 파티션을 사용하면 이전 boot 파티션의 다음 섹션은 더 이상 없습니다.

  • 2단계 부트로더: 기기에 2단계 부트로더가 있다면 이 부트로더를 자체 파티션에 저장해야 합니다.
  • DTB: DTB는 공급업체 부팅 파티션에 저장됩니다.

boot 파티션에는 다음과 같은 GKI 구성요소가 있는 CPIO 아카이브가 포함됩니다.

  • GKI 커널 모듈(/lib/modules/에 있음)
  • first_stage_init 및 종속된 라이브러리
  • fastbootd 및 recovery(A/B 및 가상 A/B 기기에 사용됨)

GKI 부팅 이미지는 Google에서 제공하며 GKI 호환성 테스트에 사용되어야 합니다.

최신 arm64 android11-5.4 boot.img는 ci.android.com의 aosp-master 분기 aosp_arm64 빌드 아티팩트에서 다운로드할 수 있습니다.

최신 arm64 android11-5.4 커널 이미지(Image.gz)는 ci.android.com의 aosp_kernel-common-android11-5.4 분기 kernel_aarch64 빌드 아티팩트에서 다운로드할 수 있습니다.

공급업체 부팅 파티션

vendor_boot 파티션은 GKI와 함께 도입되었습니다. 가상 A/B를 통해 A/B되며 헤더, 공급업체 램디스크 및 기기 트리 blob으로 구성됩니다. 공급업체 램디스크는 기기 부팅에 필요한 공급업체 모듈이 포함된 CPIO 아카이브입니다. 여기에는 기기를 부팅하고 스플래시 화면을 표시하는 데 필요한 저장소 및 디스플레이 드라이버뿐만 아니라 중요한 SoC 기능을 사용 설정하는 모듈이 포함됩니다.

CPIO 아카이브에는 다음이 포함됩니다.

  • 1단계 init 공급업체 커널 모듈(/lib/modules/에 있음)
  • modprobe 구성 파일(/lib/modules에 있음)
  • 1단계 init 중에 로드할 모듈을 나타내는 modules.load 파일

부트로더 요구사항

부트로더는 공급업체 램디스크 CPIO 이미지(vendor_boot 파티션의) 바로 다음에 일반 램디스크 CPIO 이미지(boot 파티션의)를 메모리에 로드해야 합니다. 압축 해제 이후 결과는 공급업체 램디스크의 파일 구조 위에 오버레이된 일반 램디스크입니다.

GKI 호환성 테스트

Android 11 플랫폼 출시의 경우 v5.4 커널로 출시된 기기는 Google에서 제공하는 GKI 부팅 이미지를 사용하여 VTS 및 CTS-on-GSI 테스트를 실행해야 합니다.

GKI 커널에 참여

GKI 커널은 android11-5.4부터 AOSP 일반 커널에서 빌드됩니다. 제출되는 모든 패치는 다음 2가지 전략을 문서화한 참여 가이드라인을 따라야 합니다.

  1. 최선: 업스트림 Linux를 모두 변경합니다. 적절한 경우 안정적인 출시로 백포팅합니다. 이러한 패치는 해당하는 AOSP 일반 커널에 자동으로 병합됩니다. 패치가 이미 업스트림 Linux에 있다면 아래 패치 요구사항을 준수하는 패치의 백포트를 게시합니다.
  2. 차선: 트리 외부 패치를 개발합니다(업스트림 Linux 관점에서). 패치가 Android 관련 버그를 수정하지 않는 한 kernel-team@android.com과 조정된 경우 외에는 허용될 가능성이 거의 없습니다.

GKI를 구현하는 파트너의 경우 트리 외부 패치가 필요한 타당한 이유가 있을 수 있습니다(특히 충족해야 하는 실리콘 일정이 있는 경우). 이러한 경우 Buganizer 문제를 신고합니다.

먼저 Gerrit을 통해 GKI 변경사항을 android-mainline 분기에 제출한 후 필요에 따라 다른 출시 분기로 백포팅합니다.

로더블 모듈과 관련된 소스 코드는 GKI 커널 소스 트리에 참여할 필요가 없지만 모든 드라이버를 업스트림 Linux에 제출하는 것이 좋습니다.

메인라인에서 백포트 요청

일반적으로 GKI 파트너에 필요한 메인라인 패치는 GKI 커널로 백포팅할 수 있습니다. 참여 가이드라인에 따라 Gerrit에 패치를 업로드합니다.

패치가 업스트림에 게시되었지만 아직 승인되지 않은 경우 승인될 때까지 기다리는 것이 좋습니다. 일정상의 이유로 패치가 업스트림에서 승인될 때까지 기다릴 수 없다면 Buganizer 문제를 신고합니다.

GKI 구성 추가 및 삭제

arch/arm64/configs/gki_defconfig의 구성 추가 또는 삭제를 요청하려면 요청 내용 및 근거를 명확하게 설명하여 Buganizer 문제를 신고합니다. 액세스 가능한 Buganizer 프로젝트가 없다면 구성 변경사항이 포함된 패치를 Gerrit에 게시하고 커밋 메시지에 구성이 필요한 이유를 명확하게 설명해야 합니다.

고정된 KMI 커널의 구성 변경사항은 KMI에 영향을 주지 않아야 합니다.

코어 커널 코드 수정

AOSP 일반 커널의 코어 커널 코드를 수정하지 않는 것이 좋습니다. 먼저, 패치를 업스트림 Linux로 보낸 후 백포팅합니다. 코어 커널 변경의 합당한 이유가 있다면 요청 내용 및 근거를 명확하게 설명하여 Buganizer 문제를 신고합니다. Buganizer 문제가 없다면 Android 관련 기능이 승인되지 않습니다. Buganizer 문제를 생성할 수 없는 경우 kernel-team@android.com으로 이메일을 보내주세요.

EXPORT_SYMBOL_GPL()을 통해 기호 내보내기

기호 내보내기만 포함된 패치를 업스트림에 전송하지 마세요. 업스트림 Linux 대상으로 고려되려면 EXPORT_SYMBOL_GPL()을 추가할 때 기호를 사용하는 트리 내 모듈 드라이버가 필요하므로 내보내기와 동일한 패치 세트에 새 드라이버 또는 기존 드라이버의 변경사항을 포함해야 합니다.

패치를 업스트림에 전송할 때 커밋 메시지에는 패치가 필요하고 커뮤니티에 유익한 이유에 관한 명확한 근거가 포함되어야 합니다. 트리 외부 드라이버 또는 기능의 이점을 활용하기 위해 내보내기를 사용 설정하는 것은 업스트림 운영자에게 설득력 있는 주장이 아닙니다.

어떠한 이유로든 패치를 업스트림에 전송할 수 없는 경우 Buganizer 문제를 신고하고 패치를 업스트림에 전송할 수 없는 이유를 설명합니다. 일반적으로 지원되는 커널 하위 시스템 인터페이스인 기호는 내보내기로 허용될 가능성이 있습니다. 그러나 임의의 내부 도우미 함수는 허용되지 않을 가능성이 있으며, 이 함수 사용을 방지하기 위해 코드를 리팩터링하라는 메시지가 표시됩니다.

KMI 기호 목록에 기호 추가

KMI 기호 목록은 공급업체 모듈에서 사용하는 GKI 커널 기호로 업데이트해야 합니다. KMI 기호만 안정적인 상태로 유지되므로 GKI는 KMI 기호가 아닌 기호를 사용하는 모듈이 로드되는 것을 허용하지 않습니다.

extract_symbols 스크립트는 커널 빌드 트리에서 관련 기호를 추출하며 KMI 기호 목록을 업데이트하는 데 사용될 수 있습니다. 자세한 내용은 기호 목록 문서를 참고하세요.