Linux Kernel Design Principles 정리
운영체제에서 kernel은 가장 핵심적인 구성 요소이다.
CPU scheduling, memory management, process management, file system, device driver 등 하드웨어와 소프트웨어 사이의 모든 자원 관리는 kernel이 담당한다.
kernel을 설계하는 방식에는 여러 철학이 존재하지만, 대표적으로 Monolithic Kernel과 Microkernel 구조가 있다.
Monolithic Kernel (모놀리식 커널)
Monolithic Kernel은 운영체제의 대부분 기능을 kernel space에서 실행하는 구조이다.
특징
- device driver, file system, memory management, IPC (Inter-Process Communication) 등이 모두 kernel space에서 동작
- 사용자 프로그램은 system call을 통해 kernel 기능을 사용
- Loadable Kernel Module (LKM)을 통해 실행 중에 kernel module을 동적으로 load / unload 가능
장점
- kernel 내부에서 function call 방식으로 동작하여 overhead가 적음
- context switch가 적어 performance가 우수함
- 구조가 직관적이고 구현에 필요한 code complexity가 비교적 낮음
단점
- kernel 내부의 하나의 service라도 failure가 발생하면 entire system crash로 이어질 수 있음
- 새로운 기능 추가 시 kernel 전체 수정이 필요하여 maintainability가 떨어짐
- security 측면에서 리스크가 큼
Microkernel (마이크로커널)
Microkernel은 kernel에 최소한의 기능만 남기고, 나머지 기능은 user space에서 실행하는 구조이다.
Kernel이 담당하는 최소 기능
- address space management
- thread management
- IPC
file system, device driver, network service 등은 user space에서 server 형태로 실행되며, kernel과는 IPC로 통신한다.
장점
- 특정 service가 crash 되더라도 kernel 전체에는 영향을 주지 않음
- 구조적으로 stability, security, extensibility가 뛰어남
- service의 추가, 교체, 확장이 용이함
단점
- 잦은 IPC와 context switch로 인해 performance overhead 발생
- 구조가 복잡하여 implementation complexity가 높음
Monolithic Kernel vs. Microkernel 비교
| 항목 | Microkernel | Monolithic Kernel |
|---|---|---|
| Size | 작음 | 큼 |
| Execution | 느림 | 빠름 |
| Extensibility | 높음 | 낮음 |
| Stability | service failure가 kernel에 영향 없음 | service failure 시 entire system crash |
| Code Complexity | 높음 | 낮음 |
| Example | QNX, Symbian, L4Linux | Unix, Linux, BSD, Windows |
Linux는 왜 Monolithic Kernel인가?
Linux는 전통적인 Monolithic Kernel 구조를 사용한다.
하지만 단순한 monolithic kernel이 아니라, modular monolithic kernel에 가깝다.
- device driver, file system 등을 kernel module로 분리
- 필요한 경우에만 load하여 monolithic 구조의 단점을 완화
- performance를 유지하면서 extensibility와 flexibility를 확보
👉 Linux는
Microkernel의 장점을 부분적으로 수용한 고성능 Monolithic Kernel이라고 볼 수 있다.
앙딱정
- performance 중심 설계 → Monolithic Kernel
- stability / security 중심 설계 → Microkernel
- 현실적인 타협안 → Linux의 modular monolithic kernel
왜 Kernel Module이 필요한가? - Loadable Kernel Module
object file 형태로 존재하며, runtime에 kernel에 link(적재)될 수 있는 코드
- modularity: 기능을 module로 분리해서 관리 가능
- extensibility: 필요한 기능만 runtime에 추가/제거 가능
많은 kernel 기능이 kernel build time에 built-in 또는 module로 선택 가능
예: device drivers, network protocols, file systems 등
Monolithic Kernel은 어떻게 compile하나?
커널을 전부 다시 컴파일하는 방식은 비효율적
make는 여러 component file로 이루어진 program을 대상으로
- 어떤 파일이 변경되었는지 자동으로 판단하고
- 필요한 부분만 다시 compile하도록 command를 실행해주는 tool
기존
어디가 바꼈는지 일일히 다 쳐야함
Makefile로 컴파일 시간을 줄이기
Makefile: dependency 기반 빌드 규칙을 정의하는 텍스트 파일
make는 이 규칙을 읽고, 변경된 부분만 다시 compile한다
기본 구조
target : dependency
command각 요소의 의미는 다음과 같다.
-
target
- 결과물
- 예: object file (
.o), executable file
-
dependency
- target을 만들기 위해 필요한 file
- source file 또는 object file
-
command
- 실제 실행할 shell command
-
macro
- 반복되는 값을 변수처럼 관리하기 위한 요소
2. Makefile 예제 (without macro)
intro_exe : job.o hobby.o main.o
gcc -o intro_exe job.o hobby.o main.o
job.o : job.c
gcc -c -o job.o job.c
hobby.o : hobby.c
gcc -c -o hobby.o hobby.c
main.o : main.c
gcc -c -o main.o main.c
clean :
rm *.o intro_exe이 Makefile이 하는 일
-
intro_exe는job.o,hobby.o,main.o에 의존 -
각
.o파일은 대응되는.c파일에 의존 -
make실행 시:- 변경된
.c파일에 해당하는.o만 다시 compile - 이후 필요한 경우에만 link 수행
- 변경된
clean target
-
make clean실행 시:- object file과 executable file 삭제
-
build 환경을 초기화할 때 사용
👉 이 구조가 Linux kernel build의 기본 뼈대
3. Makefile 예제 (with macro)
위 Makefile의 문제점: 중복
compiler 이름이나 target 이름이 바뀌면 여러 줄을 수정해야 함 -> macro를 사용
CC = gcc
TARGET = intro_exe
$(TARGET) : job.o hobby.o main.o
$(CC) -o $(TARGET) job.o hobby.o main.o
job.o : job.c
$(CC) -c -o job.o job.c
hobby.o : hobby.c
$(CC) -c -o hobby.o hobby.c
main.o : main.c
$(CC) -c -o main.o main.c
clean :
rm *.o intro_exemacro의 장점
CC만 바꾸면 compiler 교체 가능TARGET만 바꾸면 executable 이름 변경 가능- 가독성과 유지보수성 향상
4. OBJECTS macro와 all target
파일 수가 더 많아지면 object file 목록도 한 곳에서 관리하는 게 좋다.
CC = gcc
TARGET = intro_exe
OBJECTS = job.o hobby.o main.o
all : $(TARGET)
$(TARGET) : $(OBJECTS)
$(CC) -o $@ $(OBJECTS)
clean :
rm *.o intro_exe여기서 중요한 포인트
OBJECTS
- object file 목록을 하나의 macro로 관리
- file 추가/삭제 시 수정이 쉬움
all target
- default target
make만 입력해도 실행됨- 여러 executable을 만들 때도 활용 가능
all : App1 App2$
- 현재 rule의 target 이름
- 여기서는
intro_exe
👉 이 패턴은 kernel Makefile에서도 그대로 사용된다.
정리
- make는 빌드 과정을 자동화하는 tool
- Makefile은 dependency 기반 빌드 규칙을 정의하는 텍스트 파일
- macro를 사용하면:
- 중복 제거
- 유지보수성 향상
전체 compile ❌
변경된 부분만 incremental build ⭕
