커널 소스 코드 읽기 가이드

Linux 커널 소스 트리 구조 이해, ctags/cscope/clangd를 활용한 효율적인 코드 탐색, git 명령으로 함수 추적하기, LXR/Elixir 같은 온라인 도구 활용까지 커널 소스 읽기의 모든 것을 설명합니다.

커널 소스 트리 구조 (Source Tree Structure)

Linux 커널 소스 트리는 수천만 줄의 코드로 이루어져 있지만, 명확한 디렉토리 구조로 조직되어 있습니다. 각 디렉토리는 특정 목적을 가지며, 이 구조를 이해하는 것이 효율적인 소스 읽기의 첫걸음입니다.

최상위 디렉토리 (Top-Level Directories)

커널 소스의 최상위 디렉토리는 다음과 같이 구성됩니다.

헤더 파일 구조 (Include Directory)

헤더 파일은 커널의 API 정의를 담고 있어 소스 읽기에서 매우 중요합니다.

• include/linux/ — 커널 내부 API 헤더. 대부분의 핵심 데이터 구조와 함수가 여기 정의됩니다.
• include/uapi/ — 유저 공간 API 헤더. 시스템 콜 번호, ioctl 명령 등 유저 공간과의 인터페이스가 정의됩니다.
• include/asm-generic/ — 아키텍처 공통 헤더. 모든 아키텍처가 공유하는 기본 구현입니다.
• arch/*/include/ — 아키텍처별 헤더. asm/ 심볼릭 링크로 접근합니다.

진입점 찾기 (Finding Entry Points)

커널 코드를 읽을 때 어디서부터 시작해야 할지 막막할 수 있습니다. 다음은 주요 기능별 진입점입니다.

소스 다운로드 및 버전 관리 (Download and Version Control)

Git으로 소스 받기 (Git Clone)

Linux 커널은 Git으로 관리되며, 공식 저장소는 kernel.org에 있습니다. 최신 개발 버전을 받으려면 다음 명령을 사용합니다.

# Linus Torvalds의 공식 트리 (mainline)
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

# 특정 서브시스템 트리 (예: networking)
git clone https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git

# Stable 트리
git clone https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

Git으로 코드 검색 (Git Log and Grep)

Git은 단순한 버전 관리 도구가 아니라 강력한 코드 검색 도구입니다.

# 특정 문자열이 포함된 커밋 찾기
git log --all --grep="fix memory leak"

# 특정 함수가 변경된 커밋 찾기
git log -S "alloc_pages" --source --all

# 특정 파일의 변경 이력
git log -p mm/page_alloc.c

# 누가 특정 줄을 작성했는지 확인 (blame)
git blame -L 100,150 kernel/sched/core.c

# 전체 소스에서 패턴 검색 (git grep)
git grep "EXPORT_SYMBOL" -- "*.c"

# 특정 커밋에서 검색
git grep "kmalloc" v6.6

# 함수 정의 검색 (함수명만)
git grep -n "^[a-z_]* \+\*\?alloc_pages\s*("

브랜치와 태그 (Branches and Tags)

커널 소스를 읽을 때는 적절한 버전을 선택하는 것이 중요합니다.

# 사용 가능한 태그 목록 (안정 버전)
git tag -l "v6.*"

# 특정 버전으로 체크아웃
git checkout v6.6

# 최신 개발 버전
git checkout master

# 두 버전 간 차이 확인
git diff v6.5..v6.6 -- mm/

# 특정 서브시스템의 변경사항만 보기
git log v6.5..v6.6 -- drivers/net/

ctags 설정 및 사용 (ctags Setup and Usage)

ctags는 소스 코드의 심볼(함수, 변수, 매크로 등)을 인덱싱하여 빠르게 정의로 이동할 수 있게 해주는 전통적인 도구입니다. Vim과 Emacs 같은 편집기와 긴밀하게 통합됩니다.

ctags 설치 (Installation)

대부분의 리눅스 배포판은 두 가지 ctags 구현을 제공합니다.

• Exuberant Ctags — 전통적인 구현. 대부분 배포판의 기본값입니다.
• Universal Ctags — Exuberant Ctags의 fork로, 더 많은 언어와 기능을 지원합니다. 커널 개발에 추천합니다.

# Ubuntu/Debian
sudo apt install universal-ctags

# Fedora/RHEL
sudo dnf install ctags

# Arch Linux
sudo pacman -S ctags

태그 파일 생성 (Tag File Generation)

커널 소스 트리는 자체적으로 태그 생성을 지원합니다.

# 커널 소스 최상위 디렉토리에서
make tags          # ctags 태그 생성 (vim용)
make cscope        # cscope 데이터베이스 생성
make TAGS          # etags 생성 (emacs용)

# 특정 아키텍처만 포함 (더 빠르고 정확)
make ARCH=x86_64 tags

# 수동으로 ctags 생성 (더 세밀한 제어)
ctags -R --exclude=.git --exclude=*.o --exclude=*.a \
      --languages=C,C++ --langmap=c:+.h .

Vim에서 ctags 사용 (ctags in Vim)

Vim은 ctags를 네이티브로 지원합니다.

" ~/.vimrc에 추가
set tags=./tags,tags;$HOME  " 현재 디렉토리부터 홈까지 tags 파일 검색

Vim 내에서 다음 명령을 사용합니다.

Emacs에서 ctags 사용 (ctags in Emacs)

Emacs는 etags 형식을 사용합니다.

# TAGS 파일 생성
make TAGS

# Emacs 내에서 태그 파일 로드
M-x visit-tags-table RET /path/to/linux/TAGS RET

Emacs 내에서 다음 명령을 사용합니다.

• M-. — 태그 정의로 이동
• M-* — 이전 위치로 돌아가기
• M-x tags-search — 태그 파일 내에서 검색

cscope 설정 및 사용 (cscope Setup and Usage)

cscope는 C 코드 탐색에 특화된 도구로, ctags보다 더 강력한 검색 기능을 제공합니다. 함수 호출자 찾기, 전역 변수 참조 찾기 등 양방향 탐색이 가능합니다.

cscope 설치 (Installation)

# Ubuntu/Debian
sudo apt install cscope

# Fedora/RHEL
sudo dnf install cscope

# Arch Linux
sudo pacman -S cscope

데이터베이스 생성 (Database Generation)

# 커널 Makefile 사용 (추천)
make cscope

# 수동 생성
find . -name "*.c" -o -name "*.h" > cscope.files
cscope -b -q -k

# -b: GUI 없이 데이터베이스만 생성
# -q: 빠른 검색을 위한 역인덱스 생성
# -k: /usr/include 제외 (커널 모드)

cscope 사용법 (Usage)

cscope는 TUI(Terminal UI)와 Vim/Emacs 통합 두 가지 방식으로 사용할 수 있습니다.

# TUI 모드로 실행
cscope -d    # -d: 데이터베이스 재생성 안 함

TUI 모드에서 사용 가능한 검색 유형은 다음과 같습니다.

• Find this C symbol — 심볼의 모든 참조 찾기
• Find this global definition — 전역 정의 찾기
• Find functions called by this function — 호출하는 함수 목록
• Find functions calling this function — 호출당하는 위치 목록 (매우 유용)
• Find this text string — 문자열 검색
• Find this egrep pattern — 정규식 패턴 검색
• Find this file — 파일명 검색
• Find files #including this file — 헤더를 포함하는 파일 찾기

Vim에서 cscope 사용 (cscope in Vim)

" ~/.vimrc에 추가
if has("cscope")
  set csprg=/usr/bin/cscope
  set csto=0
  set cst
  set nocsverb
  if filereadable("cscope.out")
    cs add cscope.out
  endif
  set csverb
endif

" 키 매핑 (선택 사항)
nmap <C-\>s :cs find s <C-R>=expand("<cword>")<CR><CR>
nmap <C-\>g :cs find g <C-R>=expand("<cword>")<CR><CR>
nmap <C-\>c :cs find c <C-R>=expand("<cword>")<CR><CR>
nmap <C-\>d :cs find d <C-R>=expand("<cword>")<CR><CR>

Vim 내에서 다음 명령을 사용합니다.

clangd / ccls (LSP 기반 도구)

Language Server Protocol(LSP)는 현대적인 IDE 기능을 모든 편집기에서 사용할 수 있게 해주는 표준입니다. clangd와 ccls는 C/C++ LSP 서버로, ctags/cscope보다 훨씬 정확한 코드 분석을 제공합니다.

LSP 도구의 장점 (Advantages)

• 정확한 정의 이동 — 컴파일러 수준의 분석으로 매크로, 템플릿, 오버로딩을 정확히 처리합니다.
• 자동 완성 — 컨텍스트를 고려한 지능형 자동 완성을 제공합니다.
• 실시간 오류 검사 — 타이핑하는 동안 문법 오류와 경고를 즉시 표시합니다.
• 코드 포맷팅 — clang-format을 통합하여 일관된 코드 스타일을 유지합니다.
• 리팩토링 — 심볼 이름 변경, 함수 추출 등 자동 리팩토링을 지원합니다.

clangd 설정 (clangd Setup)

clangd를 사용하려면 먼저 compile_commands.json 파일이 필요합니다. 이 파일은 각 소스 파일을 어떻게 컴파일하는지에 대한 정보를 담고 있습니다.

# clangd 설치
sudo apt install clangd-15    # Ubuntu/Debian
sudo dnf install clang-tools-extra    # Fedora/RHEL

# 커널 소스에서 compile_commands.json 생성
# 방법 1: 커널 스크립트 사용 (Linux 5.10+)
make defconfig
scripts/clang-tools/gen_compile_commands.py

# 방법 2: bear 사용 (모든 버전)
sudo apt install bear
bear -- make -j$(nproc)

# compile_commands.json이 생성되면 clangd가 자동으로 인식

편집기 통합 (Editor Integration)

대부분의 현대 편집기는 LSP를 지원합니다.

Visual Studio Code

# clangd 확장 설치
# Extensions → "clangd" 검색 → 설치

# settings.json에 추가 (선택 사항)
{
  "clangd.arguments": [
    "--background-index",
    "--clang-tidy",
    "--header-insertion=never",
    "--compile-commands-dir=${workspaceFolder}"
  ]
}

Vim/Neovim

" vim-plug 사용 예시
Plug 'neoclide/coc.nvim', {'branch': 'release'}

" coc-settings.json에 추가
{
  "languageserver": {
    "clangd": {
      "command": "clangd",
      "args": ["--background-index"],
      "rootPatterns": ["compile_commands.json", ".git/"],
      "filetypes": ["c", "cpp", "h"]
    }
  }
}

Emacs

;; lsp-mode 사용
(use-package lsp-mode
  :hook ((c-mode . lsp)
         (c++-mode . lsp))
  :commands lsp)

(use-package lsp-ui :commands lsp-ui-mode)

ccls (대안)

ccls는 clangd의 대안으로, 일부 사용자는 더 빠르다고 평가합니다.

# ccls 설치
sudo apt install ccls    # Ubuntu 22.04+

# .ccls 파일 생성 (프로젝트 루트에)
cat > .ccls <<EOF
clang
%compile_commands.json
EOF

온라인 도구 (Online Tools)

로컬 도구 설정이 번거롭거나, 빠르게 코드를 확인하고 싶을 때 온라인 도구가 유용합니다.

Elixir (Bootlin)

URL: https://elixir.bootlin.com/

Bootlin이 운영하는 Elixir는 가장 널리 사용되는 온라인 커널 소스 브라우저입니다.

• 장점:
  • 모든 커널 버전 지원 (2.6.11부터 최신까지)
  • 심볼 검색, 정의 이동, 참조 찾기
  • 빠른 로딩 속도
  • 모바일 친화적
• 사용법:
  • 우측 상단에서 커널 버전 선택
  • 좌측 파일 트리에서 탐색
  • 심볼을 클릭하면 정의로 이동
  • 우측 "Identifier search"로 심볼 검색

LXR (Linux Cross-Referencer)

LXR은 초기의 온라인 소스 브라우저로, 현재는 대부분 Elixir로 대체되었지만 일부 사이트에서 여전히 운영됩니다.

• 주요 사이트: https://lxr.linux.no/ (비공식)
• 특징: 정규식 검색, 식별자 검색, 파일명 검색

GitHub / GitLab

커널 공식 미러가 GitHub에 있습니다.

• URL: https://github.com/torvalds/linux
• 장점:
  • GitHub UI로 익숙한 탐색
  • Blame, History, PR 확인
  • 코드 검색 (GitHub Code Search)
• 단점: Elixir보다 심볼 탐색 기능이 제한적

커널 공식 문서

URL: https://www.kernel.org/doc/html/latest/

소스 코드 내 Documentation/ 디렉토리를 Sphinx로 빌드한 공식 문서입니다.

• 주요 섹션:
  • admin-guide/ — 관리자 가이드
  • driver-api/ — 드라이버 API 문서
  • process/ — 커널 개발 프로세스
  • core-api/ — 핵심 커널 API

함수 호출 추적 방법 (Tracing Function Calls)

커널 코드를 읽을 때 가장 중요한 작업 중 하나는 함수 호출 체인을 추적하는 것입니다. "이 함수는 누가 호출하는가?", "이 함수는 어떤 함수를 호출하는가?"를 파악하는 것이 코드 이해의 핵심입니다.

순방향 추적 (Forward Tracing)

함수가 호출하는 함수를 찾는 것은 비교적 쉽습니다.

# grep으로 함수 호출 찾기
git grep "kmalloc\s*(" -- "*.c"

# cscope로 찾기
cscope -d
# → "Find functions called by this function" 선택

# clangd 사용 (VS Code / Vim)
# 함수 내부에서 "Go to Definition" (F12)

역방향 추적 (Backward Tracing)

함수를 호출하는 함수를 찾는 것은 더 중요하지만 어렵습니다.

# cscope가 가장 효과적
cscope -d
# → "Find functions calling this function" 선택

# git grep으로 찾기 (정규식 사용)
git grep -n "vfs_read\s*(" -- "*.c"

# clangd 사용 (VS Code / Vim)
# 함수 정의에서 "Find All References" (Shift+F12)

간접 호출 추적 (Indirect Calls)

커널은 함수 포인터를 광범위하게 사용합니다. 예를 들어 file_operations 구조체는 파일 시스템별로 다른 함수를 가리킵니다.

# 구조체 정의 찾기
git grep "struct file_operations.*=" -- fs/ext4/

# 예: ext4의 file_operations
# fs/ext4/file.c:
# const struct file_operations ext4_file_operations = {
#     .read_iter = ext4_file_read_iter,
#     .write_iter = ext4_file_write_iter,
#     ...
# };

# 이제 ext4_file_read_iter가 실제 구현임을 알 수 있음

Kconfig와 Makefile 읽는 법 (Understanding Kconfig and Makefile)

커널 소스를 읽을 때 C 코드만 보면 안 됩니다. Kconfig와 Makefile을 읽어야 코드가 언제 포함되는지, 어떤 조건에서 빌드되는지 이해할 수 있습니다.

Kconfig 기본 (Kconfig Basics)

Kconfig 파일은 커널 설정 옵션을 정의합니다.

# fs/ext4/Kconfig 예시
config EXT4_FS
    tristate "The Extended 4 (ext4) filesystem"
    select JBD2
    select CRC16
    select CRYPTO
    help
      This is the next generation of the ext3 filesystem.

config EXT4_USE_FOR_EXT2
    bool "Use ext4 for ext2/ext3 file systems"
    depends on EXT4_FS
    depends on EXT2_FS=n && EXT3_FS=n

주요 키워드는 다음과 같습니다.

• config — 설정 심볼 정의 (CONFIG_EXT4_FS로 확장)
• tristate — y(내장), m(모듈), n(제외) 세 가지 값
• bool — y 또는 n만 가능
• depends on — 의존성 (이 조건이 만족되어야 선택 가능)
• select — 자동으로 다른 옵션 활성화
• help — 도움말 텍스트

Makefile 기본 (Makefile Basics)

각 디렉토리의 Makefile은 빌드 대상을 정의합니다.

# fs/ext4/Makefile 예시
obj-$(CONFIG_EXT4_FS) += ext4.o

ext4-y := balloc.o bitmap.o block_validity.o dir.o ext4_jbd2.o \
          extents.o extents_status.o file.o fsmap.o fsync.o \
          hash.o ialloc.o indirect.o inline.o inode.o ioctl.o \
          mballoc.o migrate.o mmp.o move_extent.o namei.o page-io.o \
          readpage.o resize.o super.o symlink.o sysfs.o xattr.o \
          xattr_trusted.o xattr_user.o

ext4-$(CONFIG_EXT4_FS_POSIX_ACL) += acl.o
ext4-$(CONFIG_EXT4_FS_SECURITY) += xattr_security.o

주요 패턴은 다음과 같습니다.

• obj-y — 항상 내장 (vmlinux에 포함)
• obj-m — 모듈로 빌드 (.ko 파일 생성)
• obj-$(CONFIG_XXX) — 설정에 따라 빌드 (y면 내장, m이면 모듈, n이면 제외)
• ext4-y — ext4.o 모듈의 구성 파일 목록

설정으로 코드 찾기 (Finding Code by Config)

# 특정 CONFIG 심볼이 정의된 Kconfig 찾기
git grep "config EXT4_FS" -- "*Kconfig*"

# 특정 CONFIG 심볼을 사용하는 Makefile 찾기
git grep "CONFIG_EXT4_FS" -- "*Makefile*"

# 소스 코드에서 CONFIG 심볼 사용 찾기
git grep "CONFIG_EXT4_FS" -- "*.c" "*.h"

# 현재 설정 확인
grep EXT4_FS .config

Documentation/ 디렉토리 활용 (Using Documentation/)

커널 소스의 Documentation/ 디렉토리는 보물 창고입니다. 코드를 읽기 전에 관련 문서를 먼저 읽으면 시간을 크게 절약할 수 있습니다.

문서 구조 (Documentation Structure)

주요 문서 (Key Documents)

소스 읽기를 시작하기 전에 다음 문서를 추천합니다.

• process/howto.rst — 커널 개발 시작 가이드
• process/coding-style.rst — 커널 코딩 스타일 (필수)
• core-api/kernel-api.rst — 핵심 API 레퍼런스
• driver-api/basics.rst — 드라이버 개발 기초
• filesystems/vfs.rst — VFS 아키텍처
• networking/netdevices.rst — 네트워크 디바이스 드라이버

문서 빌드 (Building Documentation)

# HTML 문서 생성
make htmldocs

# PDF 생성 (LaTeX 필요)
make pdfdocs

# 생성된 문서 위치
ls Documentation/output/html/index.html

# 웹 서버로 문서 보기
python3 -m http.server 8080 --directory Documentation/output/html/

실전 예제: sys_read 구현 찾기 (Practical Example: Finding sys_read)

실제로 커널 소스를 읽는 워크플로우를 시연하기 위해, read() 시스템 콜의 구현을 찾아가는 과정을 단계별로 설명합니다.

1단계: 시스템 콜 진입점 찾기

시스템 콜은 SYSCALL_DEFINE 매크로로 정의됩니다.

# read 시스템 콜 정의 검색
git grep "SYSCALL_DEFINE.*read" -- "*.c"

# 결과 예시:
# fs/read_write.c:SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)

2단계: 구현 읽기

fs/read_write.c를 열어 SYSCALL_DEFINE3(read, ...)를 찾습니다.

// fs/read_write.c (simplified)
SYSCALL_DEFINE3(read, unsigned int, fd, char __user *, buf, size_t, count)
{
    struct fd f = fdget_pos(fd);
    loff_t pos;

    if (!f.file)
        return -EBADF;

    pos = file_pos_read(f.file);
    ssize_t ret = vfs_read(f.file, buf, count, &pos);
    if (ret >= 0)
        file_pos_write(f.file, pos);
    fdput_pos(f);
    return ret;
}

3단계: vfs_read 추적

vfs_read() 함수로 이동합니다. ctags/cscope/clangd 중 하나를 사용합니다.

# git grep으로 정의 찾기
git grep -n "^ssize_t vfs_read" -- "*.c"

# 결과: fs/read_write.c:xxx:ssize_t vfs_read(...)

// fs/read_write.c
ssize_t vfs_read(struct file *file, char __user *buf, size_t count, loff_t *pos)
{
    // 권한 검사
    if (!(file->f_mode & FMODE_READ))
        return -EBADF;

    // file_operations의 read 또는 read_iter 호출
    if (file->f_op->read_iter)
        return new_sync_read(file, buf, count, pos);
    else if (file->f_op->read)
        return file->f_op->read(file, buf, count, pos);
    else
        return -EINVAL;
}

4단계: 실제 구현 찾기

이제 파일시스템별 구현을 찾아야 합니다. 예를 들어 ext4의 경우:

# ext4의 file_operations 찾기
git grep "struct file_operations.*=" -- fs/ext4/

# fs/ext4/file.c:
# const struct file_operations ext4_file_operations = {
#     .read_iter = ext4_file_read_iter,
#     ...
# };

이제 ext4_file_read_iter()를 찾아 읽으면 됩니다.

5단계: 호출 체인 시각화

지금까지 추적한 호출 체인은 다음과 같습니다.

read() (유저 공간)
  ↓
sys_read() (fs/read_write.c)
  ↓
vfs_read() (fs/read_write.c)
  ↓
file->f_op->read_iter (함수 포인터)
  ↓
ext4_file_read_iter() (fs/ext4/file.c)
  ↓
generic_file_read_iter() (mm/filemap.c)
  ↓
page cache 또는 disk I/O

실용적인 명령어 모음 (Command Cheatsheet)

자주 사용하는 소스 탐색 명령을 빠르게 참고할 수 있도록 정리했습니다.

Git 명령어 (Git Commands)

# 함수 정의 검색
git grep -n "^int alloc_pages" -- "*.c"

# 구조체 정의 검색
git grep -n "^struct task_struct" -- "*.h"

# 매크로 정의 검색
git grep -n "#define CONFIG_" -- "*.h"

# 특정 파일 타입만 검색
git grep "kmalloc" -- "*.c"

# 대소문자 무시 검색
git grep -i "spinlock" -- "*.h"

# 단어 단위 검색 (-w)
git grep -w "init" -- "*.c"

# 줄 번호와 함수명 표시
git grep -n -p "printk" -- kernel/

# 특정 심볼이 추가/삭제된 커밋 찾기
git log -S "rcu_read_lock" --oneline

# 특정 함수를 수정한 커밋들
git log -L :schedule:kernel/sched/core.c

파일 찾기 (Finding Files)

# 파일명으로 찾기
find . -name "sched.h"

# 최근 수정된 파일 찾기
find . -name "*.c" -mtime -7

# 특정 크기 이상 파일
find . -name "*.c" -size +100k

# git ls-files 사용 (더 빠름)
git ls-files | grep sched

유용한 grep 패턴 (Useful Grep Patterns)

# 함수 정의 (반환 타입 + 함수명)
git grep -n "^\w\+\s\+\*\?\w\+\s*("

# EXPORT_SYMBOL로 export된 함수
git grep "EXPORT_SYMBOL" -- "*.c"

# 시스템 콜 정의
git grep "SYSCALL_DEFINE"

# 커널 파라미터
git grep "module_param"

# 디바이스 트리 바인딩
git grep "compatible.*=" -- "*.dts"

팁과 주의사항 (Tips and Warnings)

효율적인 읽기 팁 (Reading Tips)

흔한 실수 (Common Pitfalls)

성능 고려사항 (Performance Notes)

워크플로우 예시 (Workflow Example)

실제 커널 개발자의 일반적인 소스 읽기 워크플로우를 정리했습니다.

시나리오: 버그 수정을 위한 소스 읽기

1. 증상 파악 — 버그 리포트나 로그를 읽고 문제 영역을 특정합니다.
2. 진입점 찾기 — 시스템 콜, ioctl, 또는 커널 API로 진입점을 찾습니다.
3. 호출 체인 추적 — cscope나 clangd로 호출 관계를 따라갑니다.
4. 관련 코드 읽기 — 의심되는 함수와 그 주변 코드를 읽습니다.
5. git blame으로 히스토리 확인 — 최근 변경사항이 버그를 유발했는지 확인합니다.
6. 문서 참고 — Documentation/에서 설계 의도를 확인합니다.
7. 테스트 코드 확인 — tools/testing/selftests/에서 관련 테스트를 찾아 실행합니다.

시나리오: 새 기능 구현을 위한 소스 읽기

1. 유사 기능 찾기 — 이미 구현된 비슷한 기능을 검색합니다.
2. API 문서 읽기 — Documentation/core-api/에서 사용할 커널 API를 파악합니다.
3. 예제 드라이버 분석 — drivers/에서 레퍼런스 드라이버를 찾아 분석합니다.
4. Kconfig/Makefile 패턴 파악 — 빌드 시스템 통합 방법을 배웁니다.
5. 코딩 스타일 확인 — process/coding-style.rst를 읽고 따릅니다.

실무 소스 리딩 플레이북

실제 커널 분석에서는 "어디서부터 읽을지"보다 "어떤 순서로 좁혀갈지"가 더 중요합니다. 아래 루틴은 버그 분석과 기능 학습 모두에서 재사용 가능한 표준 절차입니다.

리딩 세션 템플릿

# 1) 대상 버전 고정
git checkout v6.12

# 2) 관심 심볼 최초 검색
git grep -n "SYSCALL_DEFINE.*openat" -- "*.c"

# 3) 호출 관계 추적
git grep -n "do_sys_openat2" -- "*.c" "*.h"

# 4) 설정 조건 확인
git grep -n "CONFIG_.*OPEN" -- "*Kconfig*" "*Makefile*" "*.c"

# 5) 변경 이력 확인
git log -L :do_sys_openat2:fs/open.c

관련 문서

커널 소스 읽기와 관련된 다른 주제를 더 깊이 이해하고 싶다면 다음 문서를 참고하세요.

• 커널 아키텍처 — 전체 구조 이해
• 빌드 시스템 — Kbuild와 Kconfig 심화
• 디버깅 — 코드 분석과 디버깅 도구
• 커널 패치 작성법 — 코드 기여 방법
• 개발 도구 — 개발 환경 구축