KMI 안정성은 모든 kernel 내부 함수의 영구 호환이 아닙니다
GKI는 공통 kernel과 하드웨어 의존 부분을 분리하는 방향의 Android kernel 구성입니다. vendor module이 사용할 수 있는 KMI는 정해진 symbol과 ABI의 범위를 갖습니다. upstream Linux의 모든 내부 API가 모든 Android release에서 안정화됐다는 뜻은 아닙니다.
| 구분 | 확인할 것 |
|---|---|
| kernel source API | 소스 코드가 어떤 함수·구조체를 사용하는지 봅니다. |
| module binary ABI / KMI | 이미 빌드된 module과 kernel이 symbol·타입·calling convention 등을 맞추는 범위를 봅니다. |
| 사용자 공간 ABI | syscall·ioctl 등 사용자 프로그램과의 경계입니다. kernel 내부 KMI와 같은 범위가 아닙니다. |
| 제품 정책 | module 서명·허용 symbol·로드 위치와 보안 정책을 추가로 확인합니다. |
rootfs를 읽는 데 필요한 module은 늦게 둘 수 없습니다
- 부트로더
커널과 초기 ramdisk를 RAM에 적재합니다.
kernel과 first-stage init이 시작됩니다.
- 초기 사용자 공간
실제 rootfs·vendor 파티션에 접근하는 데 필요한 module을 적재합니다.
저장장치·파일 시스템 경로가 준비됩니다.
- 후속 파티션 마운트
나머지 파일과 module을 읽을 수 있습니다.
필요한 후속 서비스를 시작합니다.
- 일반 실행
장치별 기능과 Android 서비스가 동작합니다.
화살표는 의존 순서입니다. 아직 읽을 수 없는 파티션 안에만 그 파티션을 읽을 driver를 넣으면 의존 관계가 순환합니다.
vendor_boot의 초기 module, vendor_dlkm 등 후속 module 저장 위치는 release·제품 구성에 맞춰 확인합니다. “.ko를 아무 vendor 디렉터리에 복사하면 부팅 중 알아서 사용한다”는 설명에는 목록·의존성·적재 주체가 빠져 있습니다. Android의 kernel module 지원 vendor_dlkm·odm_dlkm
적재 실패의 이유를 분리합니다
| 관찰 | 확인할 부분 |
|---|---|
| Unknown symbol | 제공 module의 선행 적재, symbol export, KMI 허용 범위, 빌드 조합을 확인합니다. |
| 버전·형식 불일치 | 실제 kernel 빌드·설정·symbol version과 module의 빌드 조건을 맞춥니다. |
| 서명·정책 문제 | 해당 기기의 module 검증 정책과 빌드 종류를 확인합니다. |
| module은 적재되지만 장치가 없습니다. | driver match·DT·probe·의존 자원·하드웨어 상태를 확인합니다. |
uname -r
cat /proc/modules
modinfo example.ko환경에서 제공되는 관찰 도구의 예입니다. Android shell에 modinfo가 항상 있는 것은 아닙니다. /proc/modules에 없더라도 기능이 built-in일 수 있으므로 그것만으로 driver가 없다고 판단하지 않습니다.
upstream 번호와 Android branch를 함께 기록합니다
같은 6.x 계열이라도 ACK branch·vendor patch·config·KMI 세대에 따라 사용 가능한 기능과 ABI가 다를 수 있습니다. 다른 기기에서 가져온 .ko가 우연히 적재된다는 결과를 장기 호환성의 근거로 삼지 않습니다. 분석에서는 kernel release뿐 아니라 실제 source revision과 빌드 산출물을 연결해 보관해야 합니다.