Rootfs와 Kernel 빌드 (feat Makefile)

RootFileSystem

OS에서 필요한 기본 어플리케이션이나 라이브러리 같은 기본 파일들 : 사용자 공간 파일 시스템

• /에 담기는 기본 파일 (init 프로세스, shell, 라이브러리)

init 프로세스

리눅스 커널이 가장 먼저 띄우는 1번 프로세스 (PID: 1)

• 루트파일시스템이 준비되면 /sbin/init을 맨 처음 실행함
  • systemd: 가장 유명한 init
    • /etc/systemd/아래의 설정파일들을 읽어서 서비스 실행
    • Ubuntu, fedora등이 사용
  • android init: 안드로이드 init
  • systemV: 가장 오래된 init
  • shell: shell만 실행할 수 도..

커널와 Rootfs는 다름

• 커널: 하드웨어 제어, 프로세스 및 메모리 관리
• Rootfs: 커널 외부에 존재, 사용자 프로그램 과 설정파일들 포함

커널안에 Rootfs가 포함되어있는게 아님

1. 커널 부팅
2. Rootfs 마운트
3. /sbin/init 실행
4. 사용자 공간 진입

의 순서

---

준비 과정

rootfs를 사용자가 직접구성하는건 시간이 너무 많이 들기때문에

buildroot라는 오픈소스를 사용

• buildroot는 설정파일 (make menuconfig)를 통해 해당 아키텍처, 라이브러리, 패키지 지정하고 자동으로 Rootfs 빌드
• 모든 빌드는 aarch64 기준으로 진행, 크로스 컴파일러는 Arm developer에서 다운

1. Buildroot 설정 및 빌드
   1. ARM64타겟으로 설정
   2. systemd init 시스템 사용
   3. rootfs.ext4 이미지 생성
2. 리눅스 커널 빌드
   1. Arm developer에서 제공하는 툴체인 사용
   2. 크로스 컴파일 진행
   3. 빌드 완료
3. QEMU로 실행
   1. 커널과 Rootfs를 QEMU로 구동

---

QEMU로 리눅스 실행

buildroot와 qemu를 사용하여 빌드 완료

현재 환경을 이중 가상화 구조인데

macOS -> UTM (가상 리눅스) -> QEMU (가상 리눅스)

---

Makefile

하기 전에,

잠깐 기초 내용 복습

Complie

소스코드를 어셈블리어(바이너리)로 변환 과정

ex) main.c를 gcc -c main.c하면 mian.o 생성. 여기서 main.o는 목적파일

foo.c와 bar.c를 main.c에서 include하고 있다면, foo.o bar.o main.o를 링킹

gcc main.o foo.o bar.o -o main 을 하면 목적파일들 링킹, 실행파일 main 생성

왜 사용?

if) main.c foo.c bar.c 에서 main.c만을 수정했다고 가정.

단순히 gcc명령어들로 shell script를 작성하면 main.c 수정시마다 모든 .c파일들을 컴파일해야함

-> 시간 비효율

But, Makefile을 작성하면 필요한 부분만 컴파일 가능

3요소

• target: 생성할 것
• command: 실행할 것
• dependency: 필요한 것

foo.o: foo.h foo.c
    gcc -c foo.c
bar.o: bar.h bar.c
    gcc -c bar.c
main.o: main.c foo.h bar.h
    gcc -c main.c
main: foo.o bar.o main.o
    gcc foo.o bar.o main.o -o main

ex, foo.o를 만들기 위해서는 foo.h와 foo.c가 필요하고 .o를 만들 명령어는 gcc -c foo.c이다.

만약에, foo.c가 수정되었을 경우

1. make main을 실행, 타겟이 main인거 찾음
2. main.o foo.o bar.o필요함 -> 각각 어떻게 만드는 지 또 찾음
3. foo.o를 찾음
4. foo.o의 생성 시간보다 foo.c의 수정시간이 더 나중
5. 이런 부분들만 명령어 재실행