Google은 흑인 공동체를 위한 인종 간 평등을 진전시키기 위해 노력하고 있습니다. Google에서 어떤 노력을 하고 있는지 확인하세요.
이 페이지는 Cloud Translation API를 통해 번역되었습니다.
Switch to English

일반 커널 이미지

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

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

  • 업스트림 : kernel.org의 Linux 커널
  • AOSP : AOSP 공통 커널의 추가 Android 관련 패치
  • 공급 업체 : 공급 업체의 SoC 및 주변 장치 활성화 및 최적화 패치
  • OEM / 장치 : 추가 장치 드라이버 및 사용자 지정

거의 모든 장치에는 사용자 지정 커널이 있습니다. 이것은 커널 조각화입니다.

Android 커널 계층으로 인해 조각화가 발생합니다.

그림 1. 조각화로 이어지는 Android 커널 계층 구조

단편화 비용

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

보안 업데이트는 노동 집약적입니다.

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

장기 지원 업데이트를 병합하기 어려움

LTS (장기 지원) 릴리스에는 보안 수정 및 기타 중요한 버그 수정이 포함됩니다. 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 ) 프로젝트는 코어 커널을 통합하고 SoC 및 보드 지원을 코어 커널에서로드 가능한 모듈로 이동하여 커널 조각화를 해결합니다. GKI 커널은 커널 모듈을 위한 안정적인 KMI ( Kernel Module Interface )를 제공하므로 모듈과 커널을 독립적으로 업데이트 할 수 있습니다.

GKI :

  • 는 ACK 소스에서 만들어집니다.
  • 단일 커널 바이너리 플러스 (현재는 대한 arm64 LTS 릴리스 당 아키텍처 당로드 가능한 모듈을 연결 android11-5.4android12-5.4 ).
  • 관련 ACK에서 지원하는 안드로이드 플랫폼 릴리스 테스트됩니다. 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 호환성 은 장치가 GSI (Generic System Image) 및 GKI 부팅 이미지를 boot 파티션으로 플래시하고 system 파티션의 GSI 시스템 이미지로 설치된 GKI 커널을 사용하여 VTS 및 CTS-on-GSI + GKI 테스트를 통과 함을 의미합니다. 장치는 다른 제품 커널 과 함께 제공 될 수 있으며 GKI에서 제공하지 않는로드 가능한 모듈을 사용할 수 있습니다. 그러나 제품 및 GKI 커널 모두 동일한 vendor_bootvendor 파티션에서 모듈을로드해야합니다. 따라서 모든 제품 커널은 동일한 이진 커널 모듈 인터페이스 (KMI)를 가져야합니다. 공급 업체는 GKI KMI와 호환되는 한 제품 커널에 대한 KMI를 확장 할 수 있습니다. GKI 1.0에서 공급 업체 모듈을 언로드 할 수 있어야한다는 요구 사항은 없습니다.

GKI 1.0 목표

  • 제품 커널이 GKI 커널로 대체 될 때 VTS 또는 CTS에 회귀를 도입하지 마십시오.
  • OEM 및 공급 업체의 커널 유지 관리 부담을 줄여 AOSP 공통 커널을 최신 상태로 유지합니다.
  • 기기가 새로운 Android 플랫폼 릴리스로 업그레이드 되든 새로 출시 되든 상관없이 핵심 Android 변경 사항을 커널에 포함합니다.
  • Android 사용자 공간을 깨지 마십시오.
  • 하드웨어 관련 구성 요소를 코어 커널에서로드 가능한 모듈로 분리합니다.

GKI 2.0-GKI 제품

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

GKI 2.0 목표

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

GKI 디자인

KMI 커널 브랜치

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

KMI 커널 계층

그림 4는 5.10 KMI 커널의 분기 계층 구조를 보여줍니다. android12-5.10Android S (AOSP 실험적)에 해당하는 KMI 커널이고 android13-5.10Android T (AOSP 실험적)에 해당합니다 (커밋되지 않고 향후 새로운 분기 모델이 어떻게 진행될 것인지를 보여주기 위해 표시되지 않음).

5.10 용 KMI 커널 계층

그림 4. 5.10 용 KMI 커널 계층

그림 4에서 볼 수 있듯이 KMI 분기는 개발 (dev), 안정화 (stab) 및 고정의 세 단계를 순환합니다. 이러한 단계는 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 안정성을 제공하려는 시도는 없습니다. 예를 들어, 대한 KMI android11-5.4 대한 KMI 완전히 독립적이다 android12-5.4 .

일반적으로 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 함수에서 사용하는 열거 형 값을 변경하는 새로운 열거 형 값 추가
  • 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와 공급 업체 구성 요소를 깔끔하게 분리하기 위해 boot 파티션에는 커널과 GKI 모듈이있는 램 디스크를 포함한 일반 구성 요소 만 포함됩니다. 새 버전의 부팅 헤더 (v3)가 정의되어 GKI 아키텍처 준수를 나타냅니다. 부팅 이미지의 GKI 버전은 Google에서 제공하며 GKI 호환성 테스트시 공급 업체의 부팅 이미지 버전을 대체합니다.

첫 번째 단계 init , recoveryfastbootd 용 ramdisk는 부트 로더에 의해 연결된 두 개의 CPIO 아카이브로 구성된 initramfs 이미지입니다. 첫 번째 CPIO 아카이브는 새 vendor_boot 파티션에서 가져옵니다. 두 번째는 boot 파티션에서 나옵니다.

여기에 변경 사항 요약이 제공됩니다. 자세한 내용은 공급 업체 부팅 파티션 을 참조하십시오.

부팅 파티션

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

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

boot 파티션에는 GKI 구성 요소가있는 CPIO 아카이브가 포함되어 있습니다.

  • /lib/modules/ 에있는 GKI 커널 모듈
  • first_stage_init 및 종속 라이브러리
  • fastbootdrecovery (A / B 및 가상 A / B 장치에서 사용)

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

arm64 최신 android11-5.4 boot.img 에서 다운로드 ci.android.com 에서 aosp_arm64 의 빌드 유물 aosp-master 지점입니다.

최신 arm64 android11-5.4 커널 이미지 ( Image.gz )에서 다운로드 할 수 있습니다 ci.android.comkernel_aarch64 의 빌드 유물 aosp_kernel-common-android11-5.4 지점.

공급 업체 부팅 파티션

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

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

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

부트 로더 요구 사항

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

GKI 호환성 테스트

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

GKI 커널에 기여

GKI 커널은 android11-5.4 시작하는 AOSP 공통 커널에서 빌드됩니다. 제출 된 모든 패치는 다음 두 가지 전략을 문서화 한 다음 기여 지침을 준수해야합니다.

  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() 추가하려면 심볼을 사용하는 EXPORT_SYMBOL_GPL() 모듈 식 드라이버가 필요하므로 내보내기와 동일한 패치 세트에 새 드라이버 또는 기존 드라이버의 변경 사항을 포함합니다.

패치를 업스트림으로 보낼 때 커밋 메시지에는 패치가 필요하고 커뮤니티에 유익한 이유에 대한 명확한 근거가 포함되어야합니다. 아웃 오브 트리 드라이버 또는 기능을 활용하기 위해 내보내기를 활성화하는 것은 업스트림 유지 관리자에게 설득력있는 주장이 아닙니다.

어떤 이유로 패치를 업스트림으로 보낼 수없는 경우 Buganizer 문제를 제출하고 패치를 업스트림으로 보낼 수없는 이유를 설명하십시오. 일반적으로 커널 하위 시스템에 대해 지원되는 인터페이스 인 기호는 내보내기로 허용 될 수 있습니다. 그러나 임의의 내부 도우미 함수는 허용되지 않을 수 있으며 사용을 피하기 위해 코드를 리팩터링하라는 메시지가 표시됩니다.

KMI 기호 목록에 기호 추가

KMI 기호 목록은 공급 업체 모듈에서 사용하는 GKI 커널 기호로 업데이트해야합니다. KMI 심볼 만 안정적으로 유지되기 때문에 GKI는 모듈이 비 KMI 심볼에 의존하는 경우 모듈을로드 할 수 없습니다.

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