사용자 명령과 커널 적재를 나눕니다
insmod ./example.ko는 지정한 파일의 적재를 요청하는 사용자 공간 명령입니다. modprobe example도 사용자 공간에서 실행하지만 모듈 이름·alias, 의존성 인덱스와 설정을 함께 다룹니다. modprobe에는 명시적인 파일 경로를 받는 형식도 있으므로 두 명령을 단순히 “경로 대 이름”만으로 정의하지 않습니다. insmod(8) · modprobe(8)
사용자 공간: 파일 또는 이름·alias와 의존성을 선택
커널: 모듈 이미지·재배치·매개변수·초기화 처리
드라이버: 버스의 장치 매칭과 probe, 자원 확보
실제 기능: 장치별 I/O와 오류 경로 시험
init_module와 finit_module은 모듈 이미지를 커널에 넘기는 시스템콜입니다. 전자는 메모리 이미지, 후자는 파일 디스크립터를 받습니다. 기호 재배치, 매개변수와 초기화 함수 처리는 커널 쪽입니다. 버전·서명·압축 지원 등은 실제 커널 구성과 적재 경로를 확인합니다. 명령이 성공했다고 해서 모든 하드웨어 기능이 동작하는 것은 아닙니다.
설치된 트리와 의존성 인덱스를 맞춥니다
depmod(8)는 모듈이 제공하고 요구하는 심벌을 조사해 modules.dep와 modules.dep.bin 등을 생성합니다. modprobe가 사용하는 인덱스는 대상 커널의 설치 트리와 일치해야 합니다. 다른 빌드의 .ko만 복사한 뒤 기존 인덱스로 시험하면 파일 누락과 호환성 문제를 섞게 됩니다. 패키지나 이미지 빌드에서 갱신할 트리·커널 버전부터 정합니다.
| 관찰 | 분리할 질문 |
|---|---|
| 파일을 찾지 못함 | 대상 커널의 트리와 설치 경로가 맞는가? |
| Unknown symbol | 제공 모듈·export·의존성·실제 빌드가 맞는가? |
| 형식·버전·서명 거부 | 커널 로그와 해당 빌드의 검증 정책은 무엇인가? |
| 적재됐으나 장치 없음 | 장치 등록·match·probe와 의존 자원은 준비됐는가? |
버전 검사를 강제로 건너뛰는 것을 일반적인 해결 절차로 사용하지 않습니다. 적재할 수 있다고 해서 안전한 코드인 것은 아닙니다.
alias 선택과 blacklist의 적용 범위를 구별합니다
systemd v257의 드라이버 규칙은 add 이벤트에서 MODALIAS가 있으면 kmod 적재 처리를 요청합니다. 이는 한 구현이며 모든 initramfs·보드의 자동 적재를 보장하지 않습니다. 장치가 보고하는 alias, 모듈이 제공하는 alias, 이벤트를 처리하는 구성요소를 함께 봅니다.
modprobe.d(5)의 blacklist는 해당 모듈의 내부 alias를 무시하게 합니다. modprobe의 -b는 blacklist를 모듈 이름에도 적용합니다. 그러므로 이름을 직접 지정하거나 다른 경로로 적재하는 경우까지 막는 보안 경계라고 단정할 수 없습니다. options로 넣는 모듈 매개변수도 장치 트리·버스가 제공하는 모든 자원을 대신하는 설정은 아닙니다.
적재·매칭·probe·제거 시험을 각각 기록합니다
Linux 드라이버 바인딩 문서는 장치와 드라이버의 등록, 버스별 match와 probe를 구분합니다. 모듈이 등록한 드라이버가 어떤 장치에도 붙지 않을 수 있고, 일치하는 장치가 있어도 자원 부족이나 의존성으로 probe가 실패할 수 있습니다. built-in 드라이버는 적재 모듈 목록에 없을 수도 있습니다.
delete_module(2)의 일반 제거 경로는 다른 모듈의 의존성과 사용 참조를 검사합니다. 제거 거부가 곧 커널 패닉이라는 뜻은 아닙니다. 반대로 적재·제거를 100회 통과해도 동시 접근, 실패 시 정리, 장치 분리, DMA·타이머·작업 큐의 수명이 전부 검증된 것은 아닙니다. 반복 수와 별도로 각 경로의 자원·로그·오류 지표를 정해야 합니다.
이 글에서는 모듈을 설치·적재·제거하지 않았습니다. 재공유 그림을 복제하지 않고 명령 문서와 바인딩 문서를 대조했습니다. Android GKI의 KMI와 적재 시점 및 아키텍처별 모듈 재배치와 범위를 구분합니다.
English summary. User-space module selection, kernel loading, device binding and operational tests are separate stages. Dependency metadata and blacklist rules do not certify module safety.