__initcall_start 호출 방식 로드 모듈

__initcall_start = .;
*(.initcall1.init)
*(.initcall2.init)
*(.initcall3.init)
__initcall_end = .;
http://book.51cto.com/art/201007/213623.htm
4.5.3  분석 예시
PCI 서브 시스템 을 예 로 들 어 초기 화 에 위 와 같은 매크로 표 시 를 사 용 했 는 지 분석 합 니 다.
많은 서브 시스템 과 달리 PCI 서브 시스템 의 실현 코드 는 커 널 코드 트 리 의 두 곳 에 분포 되 어 있 습 니 다. drivers / pci 는 시스템 구조 와 무관 한 부분의 코드 를 저장 하 는 것 을 제외 하고 arch / i386 / pci 는 시스템 구조 와 관련 된 부분의 코드 를 저장 하기 때문에 우 리 는 이 두 곳 에서 각각 초기 화 코드 를 찾 아야 합 니 다.
표 4.1 에서 보 듯 이 PCI 서브 시스템 의 초기 화 코드 분포 상황 입 니 다.
PCI 서브 시스템 초기 화 는 이 절 에서 설명 한 모든 xxx 를 거의 사용 합 니 다.initcall 매크로, 초기 화 도 표 4.1 에서 설명 한 메모리 저장 순서에 따라 엄 격 히 실 행 됩 니 다.
표 4.1 PCI 서브 시스템 초기 화 코드 분포 상황
문장.    건.
함수 초기 화
거대 하 다.  표.  적다
내. 예금 하 다 자리. 두다
arch/i386/pci/acpi.c
pci_acpi_init
subsys_initcall
.initcall4.init
arch/i386/pci/common.c
pcibios_init
subsys_initcall
.initcall4.init
arch/i386/pci/i386.c
pcibios_assign_resources
fs_initcall
.initcall5.init
arch/i386/pci/legacy.c
pci_legacy_init
subsys_initcall
.initcall4.init
drivers/pci/pci-acpi.c
acpi_pci_init
arch_initcall
.initcall3.init
drivers/pci/pci- driver.c
pci_driver_init
postcore_initcall
.initcall2.init
drivers/pci/pci- sysfs.c
pci_sysfs_init
late_initcall
.initcall7.init
drivers/pci/pci.c
pci_init
device_initcall
.initcall6.init
drivers/pci/proc.c
pci_proc_init
__initcall
.initcall6.init
arch/i386/pci/init.c
pci_access_init
arch_initcall
.initcall3.init
그러나 표 4.1 에서 PCI 서브 시스템 의 일부 초기 화 함 수 는 같은 서브 섹 터 에 있 음 을 발견 할 수 있 습 니 다. 앞 에는 서로 다른 서브 섹 터 간 의 함수 가 서브 섹 터 의 우선 순위 에 따라 실 행 될 뿐 같은 서브 섹 터 함수 간 의 호출 순 서 를 설명 하지 않 았 습 니 다.
물론, 우 리 는 하나의 사실 을 지적 할 수 있 습 니 다. 같은 부분 사이 에 주소 가 맨 앞 에 있 는 함수 가 먼저 호출 됩 니 다.그러나 우 리 는 어떤 함수 가 앞 에 있 고 어떤 함수 가 뒤에 있 는 지 모른다. 예 를 들 어 똑 같이 'initcall2. init 자 절 에 있 는 pcibus' 이다.class_init 함수 와 pcidriver_init 함수, 간단 한 방법 으로 판단 할 수 있 습 니까?
다음은 GCC 수첩 의 한 구절 입 니 다.
the linker searches and processes libraries and object files in the order they are specified. Thus, 'foo.o -lz bar.o' searches library 'z'  after file 'foo.o' but before 'bar.o'. 
즉, 커 넥 터 는 라 이브 러 리 파일 과 대상 파일 이 지정 한 순서에 따라 처리 되 고 pcibus 를 엽 니 다.class_init 함수 와 pcidriver_init 함수 가 있 는 디 렉 터 리 drivers / pci / 의 Makefile 파일 을 볼 수 있 습 니 다:
5 obj-y           += access.o bus.o probe.o  remove.o pci.o quirks.o \  

6                         pci-driver.o search.o  pci-sysfs.o rom.o setup-res.o 

probe. o 는 pci - driver. o 이전에 지정 되 었 기 때문에 probe. c 파일 의 pcibusclass_init 함수 가 Pci - driver. c 파일 에 있 는 Pcidriver_init 함수 가 호출 되 었 습 니 다.
pcibus 에 대해class_init 함수 와 pcidriver_init 함 수 는 같은 디 렉 터 리 위치 에 있 는 이 디 렉 터 리 Makefile 파일 이 지정 한 링크 순 서 를 통 해 판단 할 수 있 으 며,. initcall3. init 부분 에 있 는 acpipci_init 함수 와 pciaccess_init 함 수 는 이 방법 을 사용 할 수 없습니다.
acpi_pci_init 함 수 는 drivers / pci / pci - acpi. c 파일 에 있 고 pciaccess_init 함 수 는 arch / i386 / Pci / init. c 파일 에 있 습 니 다. 서로 다른 디 렉 터 리 에 있 습 니 다. 이 문 제 는 arch / i386 / Pci 의 Makefile 과 drivers / pci 의 Makefile 로 바 뀌 었 습 니 다. 이것 은 kbuild 가 커 널 을 구축 하 는 운영 체제 와 관련 됩 니 다.
커 널 에 있 는 Makefile 은 주로 다음 과 같은 세 가지 가 있 습 니 다.
커 널 소스 트 리 루트 디 렉 터 리 의 Makefile.하나만 있 지만 다른 Makefile 보다 훨씬 높 은 위 치 를 차지 하 며 시스템 구조 와 무관 한 모든 변수 와 목 표를 정의 합 니 다.
arch/*/Makefile。특정 시스템 구조 와 관련 하여 루트 디 렉 터 리 에 있 는 Makefile 에 포함 되 어 kbuild 에 시스템 구조의 특정 정 보 를 제공 합 니 다.arch / * / 디 렉 터 리 아래 각급 하위 디 렉 터 리 에 있 는 Makefile 도 포함 되 어 있 습 니 다.
drivers / 등 각 하위 디 렉 터 리 에 있 는 Makefile.
kbuild 가 커 널 을 구축 할 때 먼저 루트 디 렉 터 리 Makefile 부터 실행 하고 시스템 구조 와 무관 한 변수 와 의존 관 계 를 얻 으 며 arch / * Makefile 에서 시스템 구조의 특정한 변수 등 정 보 를 얻어 루트 디 렉 터 리 Makefile 이 제공 하 는 변 수 를 확장 합 니 다.
이 때 kbuild 는 커 널 구축 에 필요 한 모든 변수 와 목 표를 가지 고 있 습 니 다.그리고 kbuild 는 각 하위 디 렉 터 리 에 들 어가 일부 변 수 를 하위 디 렉 터 리 의 Makefile 에 전달 합 니 다. 하위 디 렉 터 리 Makefile 은 설정 정보 에 따라 어떤 원본 파일 을 컴 파일 할 지 결정 하여 컴 파일 해 야 할 파일 목록 을 만 듭 니 다.
그 다음은 커 널 컴 파일 의 긴 과정 이다.현재 arch / i386 / pci 의 Makefile 은 drivers / pci 의 Makefile 이전에 실 행 된 것 이 분명 합 니 다. 즉, Pciaccess_init 함수 acpipci_init 함수 가 실행 되 기 전에 실 행 됩 니 다.
이러한 규칙 을 파악 하면 우 리 는 특정한 서브 시스템 을 연구 할 때 초기 화 함수 의 집행 순 서 를 얻 고 이 순서에 따라 깊이 분석 할 수 있다.