Kernel Analysis-HOWTO
이 문서에서는 리눅스 커널을 구성하는 각 부분을 정의하고 그 부분을 수행하는 주된 함수와 자료 구조, 그리고 이들이 어떻게 동작하는지 (how the "wheel spins") 를 설명하려고 한다. 이 문서의 최신 버전은 http://www.bertolinux.com 에서 찾아볼 수 있다. 이 문서에 대한 개선점이나 제안 사항이 있다면 당신의 아이디어를 다음의 메일 주소를 통해 보내주기 바란다: <berto (at) bertolinux.com>. 이 문서에 사용된 코드들은 이 HOWTO 문서가 쓰여지고 있는 시점에서 최신 안정 버전인 리눅스 커널 버전 2.4.x 를 참조하였다.
Copyright (C) 2000,2001,2002 Roberto Arcomano.
Copyright (C) 2003 김남형 (한국어판).
본 문서는 여러분이 자유 소프트웨어 재단(Free Software Foundation)에서 발행한 GNU 라이브러리 일반 공개 사용권(GNU Library General Public License)의 규정(즉 사용권 2판이나 혹은 여러분의 선택에 따라 더 이후의 사용권)을 준수하는 한 재유포하거나 수정할 수 있는 자유 문서이다. 본 문서는 이것이 유용하게 사용되기를 바라는 마음으로 배포하는 것이지만, 그에 대한 어떠한 보증도 하지 않는다: 상업적인 용도나 특정한 목적에 맞게 사용 했을때 의무적으로 따라 붙는 보증도 없다. 더 자세한 내용은 GNU 라이브러리 일반 대중 사용권 (GPL) 에 대해 보기 바란다. GNU GPL 의 복사본은 여기 에서 얻을 수 있다.
당신이 이 문서를 번역하는 것은 자유이다. 하지만 그전에 다음과 같은 사항들을 참고해야 할 필요가 있다:
-
당신이 번역해서 올리고자 하는 LDP 에 이미 이 문서의 번역본이 있는지 체크한다.
-
절을 유지한다. (, , , 을 포함)
참고: TXT 파일이나 HTML 파일을 직접 번역해서는 안되고 LYX 파일을 수정해야 한다. 그래야만 이를 이용해 다른 파일 형식 (TXT, HTML, RIFF 등) 으로 변환할 수 있다. "LyX" 프로그램을 사용하기 위해서 http://www.lyx.org 에서 다운로드 받을 수 있다.
번역을 위해서 나에게 질문을 할 필요는 없다. 그저 당신의 번역물에 관해 (당신이 원한다면) 내가 알 수 있게만 해주면 된다.
당신의 번역에 감사한다!
함수에 대해서 설명할 때는 다음과 같은 형태로 표기한다:
예를 들어:
예 1. "schedule [ kernel/sched.c ]"
라는 표현이 있을 때 이것은 우리가 지금
이라는 함수에 관해서 설명하고 있음을 나타내며, 이 함수는
라는 파일에서 찾아볼 수 있음을 뜻한다.
참고: 여기서는 시작 디렉토리가 /usr/src/linux 라고 가정하고 있는 것이다.
소스 코드 안에서의 들여쓰기에는 3개의 공백문자가 사용되었다.
이 문서에서는 커널 함수들의 호출 관계를 표현하기 위해 (들여쓰기의 방식으로) "함수간 호출 분석 (InterCalling Analysis : ICA)" 을 사용한다.
예를 들어 sleep_on 이라는 함수를 함수간 호출 분석을 통해 표현하면 아래와 같다:
|sleep_on
|init_waitqueue_entry --
|__add_wait_queue | enqueuing request
|list_add |
|__list_add --
|schedule --- waiting for request to be executed
|__remove_wait_queue --
|list_del | dequeuing request
|__list_del --
sleep_on ICA
|
들여쓰기로 표현된 함수간 호출 분석 뒤에는 함수의 위치가 나온다:
-
sleep_on [kernel/sched.c]
-
init_waitqueue_entry [include/linux/wait.h]
-
__add_wait_queue
-
list_add [include/linux/list.h]
-
__list_add
-
schedule [kernel/sched.c]
-
__remove_wait_queue [include/linux/wait.h]
-
list_del [include/linux/list.h]
-
__list_del
참고: 함수의 위치가 바로 앞에 표시한 함수의 위치와 같은 경우에는 명시하지 않았다.
함수간 호출 분석에서 다음과 같은 형태가 있을 것이다:
이것은 function1 은 다른 함수를 가리키는 일반적인 포인터라는 것을 뜻한다. 위의 경우에서 function1 은 function2 를 가리킨다.
또 다음과 같은 형태에서는:
function 은 함수가 아님을 뜻한다. 이것은 레이블이다 (일반적으로 어셈블러 레이블일 것이다).
이 문서에서는 많은 절에서 C 코드의 형태나 슈도-코드 의 형태로 표현하였다. 실제의 소스 파일에는 이것들이 어셈블러 코드나 구조화 되지 않은 코드의 형태로 들어있을 수도 있다. 이러한 차이점은 학습을 위한 것이다.
함수간 호출 분석 (ICA) 를 사용하는데 있어서 다음과 같은 많은 장점들이 있다:
-
커널 함수를 호출하였을 때 어떤 일이 일어나는 가를 전체적으로 알 수 있다.
-
함수의 뒤에 함수의 위치가 나오므로, 함수간 호출 분석을 하나의 함수의 레퍼런스 로도 사용할 수 있다.
-
함수간 호출 분석은 sleep/awake 메카니즘에서 유용하다. 이를 이용해 프로세스가 sleep 되기 전에 어떤 일을 하는지와 (스케줄 이후에) wake up 이후에 무슨 일을 할 것인지를 볼 수 있다.
함수간 호출 분석 (ICA) 를 사용하는데 있어서 다음과 같은 단점들이 있다:
-
모든 이론적인 모델에 있어서, 실제 소스코드와 특정한 조건들과 같은 자세한 사항들을 제외하고 단순화 시켰다.
-
스택의 상태, 데이타의 값 등을 표현하기 위해서는 추가적인 표현이 추가되어야 한다.
커널이란 컴퓨터 시스템의 핵심(core) 부분을 말한다.
즉, 컴퓨터의 자원들을 사용자가 공유할 수 있도록 해주는 소프트웨어 이다.
커널은 (그래픽을 이용한 관리 프로그램도 포함할 수 있는) 운영체제의 주요 소프트웨어라고 생각할 수 있을 것이다.
예를 들어, (다른 Unix 기반의 운영체제와 같이) 리눅스에서는 X 윈도우 환경은 커널에 속해있지 않다. 왜냐하면 X 윈도우 환경은 오직 그래픽 연산 만을 관리하기 때문이다. (비디오 카드 장치에 접근하기 위해서 사용자 모드의 I/O 를 사용한다.)
대조적으로 윈도우즈 환경 (Win9x, WinME, WinNT, Win2K, WinXP 등) 에서는 커널과 그래픽 환경이 혼합되어 있다.
(컴퓨터가 방 한개를 차지할 만큼의 크기였던) 예전에는 사용자들이 응용 프로그램을 실행시키는 것도 무척 힘든 일이었고, 때때로 응용 프로그램이 컴퓨터를 망가뜨리기도 하였다.
위와 같이 응용 프로그램이 시스템을 망가뜨리는 것을 방지하기 위해, 이후의 운영체제들은 2 가지의 다른 동작 모드를 갖도록 디자인되었다.
-
커널 모드: 중요한 자료구조나 직접적인 하드웨어 접근 (I/O 혹은 memory mapped), 직접적인 메모리 접근, IRQ, DMA 등의 처리
-
사용자 모드: 사용자가 응용 프로그램을 실행할 수 있음
| Applications /|\
| ______________ |
| | User Mode | |
| ______________ |
| | |
Implementation | _______ _______ | Abstraction
Detail | | Kernel Mode | |
| _______________ |
| | |
| | |
| | |
\|/ Hardware |
|
커널 모드에서는 사용자 모드의 응용 프로그램이 시스템 자체나 시스템의 기능에 손상을 입히는 것을 방지 한다.
근래의 마이크로 프로세스들은 하드웨어 적으로 최소한 2 가지 이상의 상태를 구현하고 있다. 예를 들어 인텔에서는, 4 가지 상태로 PL (Privilege Level: 특권 레벨) 결정한다. 즉, 0, 1, 2, 3 의 4 가지 상태를 사용할 수 있으며 이 중에서 커널 모드는 0 을 사용한다.
유닉스 기반의 운영체제는 오직 2 단계의 특권 레벨을 필요로 하며, 앞으로 이러한 개념이 코드 상에서 어떻게 이용되는지 보게 될 것이다.
위의 2 가지 모드를 이해했다면, 다음으로 이러한 2 가지 모드 사이의 전환이 언제 일어나는지를 알아야 한다.
일반적으로 이러한 전환이 일어나는 경우는 다음의 2 가지 경우이다:
-
시스템 콜을 호출했을 때: 시스템 콜을 호출한 이후에, 프로세스는 자동적으로 커널 모드에 있는 코드를 호출한다.
-
IRQ (혹은 예외) 가 발생했을 때: 인터럽트 요청 (InterRupt reQuest: IRQ) 이 발생한 후에, 인터럽트 핸들러 (혹은 예외 핸들러) 가 호출되고, (인터럽트 처리가 끝나면) 제어경로는 아무 일도 없었던 듯이 (사용자 모드의) 프로세스로 돌아간다.
시스템 콜은 커널 모드 내에 있는 운영체제 루틴들을 관리하는 특별한 함수라고 할 수 있다.
시스템 콜은 다음과 같은 경우에 호출된다:
-
I/O 장치나 파일에 접근할 때 (read/write)
-
특권이 있는 정보에 접근할 필요가 있을 때 (pid, 스케줄링 정책 등)
-
실행 환경을 바꿔야 할 때 (fork, exec)
-
특정한 명령을 수행해야 할 때 (chdir, kill, brk, signal 등)
| |
------->| System Call i | (Accessing Devices)
| | | | [sys_read()] |
| ... | | | |
| system_call(i) |-------- | |
| [read()] | | |
| ... | | |
| system_call(j) |-------- | |
| [get_pid()] | | | |
| ... | ------->| System Call j | (Accessing kernel data structures)
| | | [sys_getpid()]|
| |
USER MODE KERNEL MODE
Unix System Calls Working
|
시스템 콜은 사용자 모드에서 로우 레벨의 자원 (하드웨어) 과 통신을 위해 사용할 수 있는 거의 유일한 인터페이스이다. 이에 대한 단 하나의 예외 사항으로는 프로세스에서 ioperm 을 호출한 경우이다. 이 경우에는 사용자 모드에서 장치에 직접 접근할 수 있다. (IRQ 는 사용되지 않는다.)
참고: 모든 C 언어 함수가 시스템 콜인 것이 아니라 그중 일부 만이 시스템 콜이다.
다음의 리스트는 리눅스 커널 2.4.17 의 시스템 콜의 목록을 보여준다. [ arch/i386/kernel/entry.S ]
.long SYMBOL_NAME(sys_ni_syscall) /* 0 - old "setup()" system call*/
.long SYMBOL_NAME(sys_exit)
.long SYMBOL_NAME(sys_fork)
.long SYMBOL_NAME(sys_read)
.long SYMBOL_NAME(sys_write)
.long SYMBOL_NAME(sys_open) /* 5 */
.long SYMBOL_NAME(sys_close)
.long SYMBOL_NAME(sys_waitpid)
.long SYMBOL_NAME(sys_creat)
.long SYMBOL_NAME(sys_link)
.long SYMBOL_NAME(sys_unlink) /* 10 */
.long SYMBOL_NAME(sys_execve)
.long SYMBOL_NAME(sys_chdir)
.long SYMBOL_NAME(sys_time)
.long SYMBOL_NAME(sys_mknod)
.long SYMBOL_NAME(sys_chmod) /* 15 */
.long SYMBOL_NAME(sys_lchown16)
.long SYMBOL_NAME(sys_ni_syscall) /* old break syscall holder */
.long SYMBOL_NAME(sys_stat)
.long SYMBOL_NAME(sys_lseek)
.long SYMBOL_NAME(sys_getpid) /* 20 */
.long SYMBOL_NAME(sys_mount)
.long SYMBOL_NAME(sys_oldumount)
.long SYMBOL_NAME(sys_setuid16)
.long SYMBOL_NAME(sys_getuid16)
.long SYMBOL_NAME(sys_stime) /* 25 */
.long SYMBOL_NAME(sys_ptrace)
.long SYMBOL_NAME(sys_alarm)
.long SYMBOL_NAME(sys_fstat)
.long SYMBOL_NAME(sys_pause)
.long SYMBOL_NAME(sys_utime) /* 30 */
.long SYMBOL_NAME(sys_ni_syscall) /* old stty syscall holder */
.long SYMBOL_NAME(sys_ni_syscall) /* old gtty syscall holder */
.long SYMBOL_NAME(sys_access)
.long SYMBOL_NAME(sys_nice)
.long SYMBOL_NAME(sys_ni_syscall) /* 35 */ /* old ftime syscall holder */
.long SYMBOL_NAME(sys_sync)
.long SYMBOL_NAME(sys_kill)
.long SYMBOL_NAME(sys_rename)
.long SYMBOL_NAME(sys_mkdir)
.long SYMBOL_NAME(sys_rmdir) /* 40 */
.long SYMBOL_NAME(sys_dup)
.long SYMBOL_NAME(sys_pipe)
.long SYMBOL_NAME(sys_times)
.long SYMBOL_NAME(sys_ni_syscall) /* old prof syscall holder */
.long SYMBOL_NAME(sys_brk) /* 45 */
.long SYMBOL_NAME(sys_setgid16)
.long SYMBOL_NAME(sys_getgid16)
.long SYMBOL_NAME(sys_signal)
.long SYMBOL_NAME(sys_geteuid16)
.long SYMBOL_NAME(sys_getegid16) /* 50 */
.long SYMBOL_NAME(sys_acct)
.long SYMBOL_NAME(sys_umount) /* recycled never used phys() */
.long SYMBOL_NAME(sys_ni_syscall) /* old lock syscall holder */
.long SYMBOL_NAME(sys_ioctl)
.long SYMBOL_NAME(sys_fcntl) /* 55 */
.long SYMBOL_NAME(sys_ni_syscall) /* old mpx syscall holder */
.long SYMBOL_NAME(sys_setpgid)
.long SYMBOL_NAME(sys_ni_syscall) /* old ulimit syscall holder */
.long SYMBOL_NAME(sys_olduname)
.long SYMBOL_NAME(sys_umask) /* 60 */
.long SYMBOL_NAME(sys_chroot)
.long SYMBOL_NAME(sys_ustat)
.long SYMBOL_NAME(sys_dup2)
.long SYMBOL_NAME(sys_getppid)
.long SYMBOL_NAME(sys_getpgrp) /* 65 */
.long SYMBOL_NAME(sys_setsid)
.long SYMBOL_NAME(sys_sigaction)
.long SYMBOL_NAME(sys_sgetmask)
.long SYMBOL_NAME(sys_ssetmask)
.long SYMBOL_NAME(sys_setreuid16) /* 70 */
.long SYMBOL_NAME(sys_setregid16)
.long SYMBOL_NAME(sys_sigsuspend)
.long SYMBOL_NAME(sys_sigpending)
.long SYMBOL_NAME(sys_sethostname)
.long SYMBOL_NAME(sys_setrlimit) /* 75 */
.long SYMBOL_NAME(sys_old_getrlimit)
.long SYMBOL_NAME(sys_getrusage)
.long SYMBOL_NAME(sys_gettimeofday)
.long SYMBOL_NAME(sys_settimeofday)
.long SYMBOL_NAME(sys_getgroups16) /* 80 */
.long SYMBOL_NAME(sys_setgroups16)
.long SYMBOL_NAME(old_select)
.long SYMBOL_NAME(sys_symlink)
.long SYMBOL_NAME(sys_lstat)
.long SYMBOL_NAME(sys_readlink) /* 85 */
.long SYMBOL_NAME(sys_uselib)
.long SYMBOL_NAME(sys_swapon)
.long SYMBOL_NAME(sys_reboot)
.long SYMBOL_NAME(old_readdir)
.long SYMBOL_NAME(old_mmap) /* 90 */
.long SYMBOL_NAME(sys_munmap)
.long SYMBOL_NAME(sys_truncate)
.lng SYMBOL_NAME(sys_ftruncate)
.long SYMBOL_NAME(sys_fchmod)
.long SYMBOL_NAME(sys_fchown16) /* 95 */
.long SYMBOL_NAME(sys_getpriority)
.long SYMBOL_NAME(sys_setpriority)
.long SYMBOL_NAME(sys_ni_syscall) /* old profil syscall holder */
.long SYMBOL_NAME(sys_statfs)
.long SYMBOL_NAME(sys_fstatfs) /* 100 */
.long SYMBOL_NAME(sys_ioperm)
.long SYMBOL_NAME(sys_socketcall)
.long SYMBOL_NAME(sys_syslog)
.long SYMBOL_NAME(sys_setitimer)
.long SYMBOL_NAME(sys_getitimer) /* 105 */
.long SYMBOL_NAME(sys_newstat)
.long SYMBOL_NAME(sys_newlstat)
.long SYMBOL_NAME(sys_newfstat)
.long SYMBOL_NAME(sys_uname)
.long SYMBOL_NAME(sys_iopl) /* 110 */
.long SYMBOL_NAME(sys_vhangup)
.long SYMBOL_NAME(sys_ni_syscall) /* old "idle" system call */
.long SYMBOL_NAME(sys_vm86old)
.long SYMBOL_NAME(sys_wait4)
.long SYMBOL_NAME(sys_swapoff) /* 115 */
.long SYMBOL_NAME(sys_sysinfo)
.long SYMBOL_NAME(sys_ipc)
.long SYMBOL_NAME(sys_fsync)
.long SYMBOL_NAME(sys_sigreturn)
.long SYMBOL_NAME(sys_clone) /* 120 */
.long SYMBOL_NAME(sys_setdomainname)
.long SYMBOL_NAME(sys_newuname)
.long SYMBOL_NAME(sys_modify_ldt)
.long SYMBOL_NAME(sys_adjtimex)
.long SYMBOL_NAME(sys_mprotect) /* 125 */
.long SYMBOL_NAME(sys_sigprocmask)
.long SYMBOL_NAME(sys_create_module)
.long SYMBOL_NAME(sys_init_module)
.long SYMBOL_NAME(sys_delete_module)
.long SYMBOL_NAME(sys_get_kernel_syms) /* 130 */
.long SYMBOL_NAME(sys_quotactl)
.long SYMBOL_NAME(sys_getpgid)
.long SYMBOL_NAME(sys_fchdir)
.long SYMBOL_NAME(sys_bdflush)
.long SYMBOL_NAME(sys_sysfs) /* 135 */
.long SYMBOL_NAME(sys_personality)
.long SYMBOL_NAME(sys_ni_syscall) /* for afs_syscall */
.long SYMBOL_NAME(sys_setfsuid16)
.long SYMBOL_NAME(sys_setfsgid16)
.long SYMBOL_NAME(sys_llseek) /* 140 */
.long SYMBOL_NAME(sys_getdents)
.long SYMBOL_NAME(sys_select)
.long SYMBOL_NAME(sys_flock)
.long SYMBOL_NAME(sys_msync)
.long SYMBOL_NAME(sys_readv) /* 145 */
.long SYMBOL_NAME(sys_writev)
.long SYMBOL_NAME(sys_getsid)
.long SYMBOL_NAME(sys_fdatasync)
.long SYMBOL_NAME(sys_sysctl)
.long SYMBOL_NAME(sys_mlock) /* 150 */
.long SYMBOL_NAME(sys_munlock)
.long SYMBOL_NAME(sys_mlockall)
.long SYMBOL_NAME(sys_munlockall)
.long SYMBOL_NAME(sys_sched_setparam)
.long SYMBOL_NAME(sys_sched_getparam) /* 155 */
.long SYMBOL_NAME(sys_sched_setscheduler)
.long SYMBOL_NAME(sys_sched_getscheduler)
.long SYMBOL_NAME(sys_sched_yield)
.long SYMBOL_NAME(sys_sched_get_priority_max)
.long SYMBOL_NAME(sys_sched_get_priority_min) /* 160 */
.long SYMBOL_NAME(sys_sched_rr_get_interval)
.long SYMBOL_NAME(sys_nanosleep)
.long SYMBOL_NAME(sys_mremap)
.long SYMBOL_NAME(sys_setresuid16)
.long SYMBOL_NAME(sys_getresuid16) /* 165 */
.long SYMBOL_NAME(sys_vm86)
.long SYMBOL_NAME(sys_query_module)
.long SYMBOL_NAME(sys_poll)
.long SYMBOL_NAME(sys_nfsservctl)
.long SYMBOL_NAME(sys_setresgid16) /* 170 */
.long SYMBOL_NAME(sys_getresgid16)
.long SYMBOL_NAME(sys_prctl)
.long SYMBOL_NAME(sys_rt_sigreturn)
.long SYMBOL_NAME(sys_rt_sigaction)
.long SYMBOL_NAME(sys_rt_sigprocmask) /* 175 */
.long SYMBOL_NAME(sys_rt_sigpending)
.long SYMBOL_NAME(sys_rt_sigtimedwait)
.long SYMBOL_NAME(sys_rt_sigqueueinfo)
.long SYMBOL_NAME(sys_rt_sigsuspend)
.long SYMBOL_NAME(sys_pread) /* 180 */
.long SYMBOL_NAME(sys_pwrite)
.long SYMBOL_NAME(sys_chown16)
.long SYMBOL_NAME(sys_getcwd)
.long SYMBOL_NAME(sys_capget)
.long SYMBOL_NAME(sys_capset) /* 185 */
.long SYMBOL_NAME(sys_sigaltstack)
.long SYMBOL_NAME(sys_sendfile)
.long SYMBOL_NAME(sys_ni_syscall) /* streams1 */
.long SYMBOL_NAME(sys_ni_syscall) /* streams2 */
.long SYMBOL_NAME(sys_vfork) /* 190 */
.long SYMBOL_NAME(sys_getrlimit)
.long SYMBOL_NAME(sys_mmap2)
.long SYMBOL_NAME(sys_truncate64)
.long SYMBOL_NAME(sys_ftruncate64)
.long SYMBOL_NAME(sys_stat64) /* 195 */
.long SYMBOL_NAME(sys_lstat64)
.long SYMBOL_NAME(sys_fstat64)
.long SYMBOL_NAME(sys_lchown)
.long SYMBOL_NAME(sys_getuid)
.long SYMBOL_NAME(sys_getgid) /* 200 */
.long SYMBOL_NAME(sys_geteuid)
.long SYMBOL_NAME(sys_getegid)
.long SYMBOL_NAME(sys_setreuid)
.long SYMBOL_NAME(sys_setregid)
.long SYMBOL_NAME(sys_getgroups) /* 205 */
.long SYMBOL_NAME(sys_setgroups)
.long SYMBOL_NAME(sys_fchown)
.long SYMBOL_NAME(sys_setresuid)
.long SYMBOL_NAME(sys_getresuid)
.long SYMBOL_NAME(sys_setresgid) /* 210 */
.long SYMBOL_NAME(sys_getresgid)
.long SYMBOL_NAME(sys_chown)
.long SYMBOL_NAME(sys_setuid)
.long SYMBOL_NAME(sys_setgid)
.long SYMBOL_NAME(sys_setfsuid) /* 215 */
.long SYMBOL_NAME(sys_setfsgid)
.long SYMBOL_NAME(sys_pivot_root)
.long SYMBOL_NAME(sys_mincore)
.long SYMBOL_NAME(sys_madvise)
.long SYMBOL_NAME(sys_getdents64) /* 220 */
.long SYMBOL_NAME(sys_fcntl64)
.long SYMBOL_NAME(sys_ni_syscall) /* reserved for TUX */
.long SYMBOL_NAME(sys_ni_syscall) /* Reserved for Security */
.long SYMBOL_NAME(sys_gettid)
.long SYMBOL_NAME(sys_readahead) /* 225 */
|
IRQ 가 발생하면 현재 실행중인 프로세스는 IRQ 핸들러를 실행하기 위해 인터럽트 된다.
IRQ 가 처리된 후, 제어 경로는 마치 아무 일도 없던 것처럼 인터럽트가 걸린 지점으로 되돌아 간다.
Running Task
|-----------| (3)
NORMAL | | | [break execution] IRQ Handler
EXECUTION (1)| | | ------------->|---------|
| \|/ | | | does |
IRQ (2)---->| .. |-----> | some |
| | |----- | work |
BACK TO | | | | | ..(4). |
NORMAL (6)| \|/ | -------------|_________|
EXECUTION |___________| [return to code]
(5)
USER MODE KERNEL MODE
User->Kernel Mode Transition caused by IRQ event
|
아래의 순서가 매겨진 단계는 위의 그림에서 나타나는 이벤트의 번호에 해당한다:
-
프로세스가 실행되고 있음
-
실행 도중 IRQ 발생
-
프로세스는 인터럽트 되고 인터럽트 핸들러 호출
-
인터럽트 핸들러 코드 수행
-
제어 경로는 (아무 일도 없던 것처럼) 사용자 모드의 프로세스로 돌아감
-
프로세스가 다시 실행
특히 관심있게 지켜보아야 할 것은 Timer IRQ 이다. Timer IRQ 는 타이머가 설정된 매 시간 간격 (ms 단위) 마다 발생하며 다음과 같은 것들을 관리한다:
-
알람
-
(프로세스 스케줄링 이나 통계 등에서 사용되는) 시스템 카운터와 태스크 카운터
-
타임 슬라이스 에 기반을 둔 멀티 태스킹
최근의 운영체제에서의 핵심은 태스크 (task, 작업) 이다. 태스크는 메모리 상에서 동작하는 응용 프로그램으로서 다른 태스크 들과 모든 자원들을 (CPU 와 메모리 등을 포함) 공유한다.
이러한 자원의 공유 는 멀티태스킹 메카니즘 에 의해서 관리된다. 멀티태스킹 메카니즘은 타임 슬라이스 로 정해진 시간이 흐르면 현재의 태스크를 다른 태스크로 교체한다. 사용자는 모든 자원을 점유하고 있는 것 같은 환상 에 빠지게 된다. 또한 한명의 사용자가 시스템을 사용하고 있는 시나리오를 생각해 보면, 마찬가지로 사용자는 많은 태스크들이 동시에 수행되고 있는 것과 같은 환상 에 빠지게 된다.
이러한 멀티태스킹을 구현하기 위해서 태스크는 다음과 같은 상태 변수를 가진다:
-
READY, 실행할 준비가 되어 있다.
-
BLOCKED, 자원을 기다리고 있다.
태스크의 상태는 그에 관련된 리스트 (READY 리스트와 BLOCKED 리스트) 내에 태스크가 속해 있는지에 의해서 관리된다.
(실행중인) 한 태스크에서 다른 태스크로 이동하는 것을 태스크 교환 (context switching (문맥 교환) 이라고 부르기도 한다) 이라고 한다. 많은 컴퓨터는 이러한 작업을 자동으로 수행해 주는 하드웨어적인 명령을 가지고 있다. 태스크 교환은 다음과 같은 경우에 일어난다:
-
타임 슬라이스 종료 후: 실행할 준비가 된 태스크를 스케줄링하여 실행한다.
-
태스크가 어떤 장치를 기다리는 경우: 새로운 태스크를 스케줄링하여 교환한다.
태스크 교환은 Schedule 개체에 의해서 관리된다.
Timer | |
IRQ | | Schedule
| | | ________________________
|----->| Task 1 |------------------>|(1)Chooses a Ready Task |
| | | |(2)Task Switching |
| |___________| |________________________|
| | | /|\
| | | |
| | | |
| | | |
| | | |
|----->| Task 2 |-------------------------------|
| | | |
| |___________| |
. . . . .
. . . . .
. . . . .
| | | |
| | | |
------>| Task N |--------------------------------
| |
|___________|
Task Switching based on TimeSlice
|
리눅스에서 타임 슬라이스는 일반적으로 10 ms 이다.
| |
| | Resource _____________________________
| Task 1 |----------->|(1) Enqueue Resource request |
| | Access |(2) Mark Task as blocked |
| | |(3) Choose a Ready Task |
|___________| |(4) Task Switching |
|_____________________________|
|
|
| | |
| | |
| Task 2 |-------------------------
| |
| |
|___________|
Task Switching based on Waiting for a Resource
|
지금까지 우리가 살펴본 것은 모놀리틱 OS 라 불리는 것들 이었지만, 마이크로커널
이라고 하는 방식의 운영체제도 있다.
마이크로커널 방식의 운영체제는 사용자 모드의 프로세스는 물론 플로피 디스크 관련 태스크,
하드 디스크 관련 태스크, 네트워크 관련 작업 등 커널이 처리하는 작업 들도 태스크 방식으로 처리한다.
이러한 방식의 운영체제로는 Amoeba,
Mach 등이 있다.
장점:
단점:
개인적인 의견으로는 마이크로커널 방식은 교육용 예제로는 적절하지만 (Minix 처럼) 실제로 적용될 수 있을 만큼
최적의 운영체제는 아니라고 생각한다. 리눅스에서는 마이크로커널의 구조를 약간
구현하여 커널 스레드 라고 불리는 몇가지 태스크를 사용한다. (하드 디스크와 같은
저장 장치에서 (스왑아웃된) 페이지를 다시 받아오는 kswapd 와 같은 태스크가 있다.)
이 경우 스와핑은 매우 느린 작업이기 때문에 성능면에서 문제될 것은 없다.
ISO-OSI 표준은 다음과 같은 계층들로 이루어진 네트워크 구조를 설명하고 있다:
-
물리적인 계층 (예: PPP, Ethernet)
-
데이타-링크 계층 (예: PPP, Ethernet)
-
네트워크 계층 (예: IP, X.25)
-
전송 계층 (예: TCP, UDP)
-
세션 계층 (예: SSL)
-
표현 계층 (예: FTP 의 binary-ascii 코딩)
- 응용 계층 (예: 네스케이프와 같은 응용 프로그램)
위의 리스트 중에서 처음 2 개의 계층은 주로 하드웨어로 구현된다. 나머지 계층들은 소프트웨어에 속한다. (혹은 펌웨어나 라우터)
운영체제는 많은 프로토콜을 사용하고 있으며 그 중의 하나로는 TCP/IP 를 들 수 있다. (이것은 3-4 계층의 가장 주된 프로토콜이다.)
ISO-OSI 계층의 처음 2 가지에 대해서는 커널은 (주소를 제외하고) 아무 것도 알지 못한다.
RX (수신) 시에 커널이 하는 일은:
-
(이더넷 카드나 모뎀과 같은) 로우 레벨 장치와의 연결(handshake)을 관리하고 그 장치들로부터 프레임 을 받아온다.
-
그 (이더넷이나 PPP 같은) 프레임 으로부터 TCP/IP 패킷 을 구성한다.
-
패킷 을 소켓 으로 변환하여 (포트 번호에 맞는) 적절한 응용프로그램에게 넘겨주거나
-
패킷 을 적절한 큐에 보내준다.
frames packets sockets
NIC ---------> Kernel ----------> Application
| packets
--------------> Forward
- RX -
|
TX (송신) 시에 커널이 하는 일은:
-
소켓 을 패킷 으로 변환하거나
-
큐에 들어있는 정보를 가져와서 패킷 을 구성한다.
-
패킷 을 (이더넷이나 PPP 에서 사용되는) 프레임 으로 분리한다.
-
하드웨어 장치를 사용해서 프레임 을 전송한다.
sockets packets frames
Application ---------> Kernel ----------> NIC
packets /|\
Forward -------------------
- TX -
|
세그먼테이션은 메모리 할당 문제를 해결하는 첫번째 방법이다: 이를 이용하면 소스코드가 메모리 상의 어느 부분에 놓이게 될지를 신경쓰지 않고도 프로그램을 컴파일할 수 있다. 실제로 이러한 기능은 응용 프로그램 개발자에게 OS 와 하드웨어에 독립적인 프로그램을 개발할 수 있도록 해준다.
| Stack |
| | |
| \|/ |
| Free |
| /|\ | Segment ---> Process
| | |
| Heap |
| Data uninitialized |
| Data initialized |
| Code |
|____________________|
Segment
|
세그먼트는 프로그램의 논리적인 개체, 혹은 메모리 상의 프로그램에 대한 이미지라고 말 할 수 있다.
프로그래밍시에 우리는 데이타가 메모리 상의 어느 부분에 놓이게 될 지 전혀 고려하지 않는다. 오직 세그먼트 (프로그램) 내에서의 위치(offset)에 대해서만 생각할 뿐이다.
보통 각각의 프로세스에 대해서 하나의 세그먼트를 할당하거나 혹은 그 반대이지만 리눅스에서는 그렇게 하지 않는다.
리눅스에서는 커널과 다른 모든 프로세스들에 대해 오직 4 개의 세그먼트 만을 사용한다.
____________________
----->| |----->
| IN | Segment A | OUT
____________________ | |____________________|
| |____| | |
| Segment B | | Segment B |
| |____ | |
|____________________| | |____________________|
| | Segment C |
| |____________________|
----->| Segment D |----->
IN |____________________| OUT
Segmentation problem
|
위의 그림에서 A 와 D 라는 프로세스(세그먼트)를 없애고 새로 B 라는 프로세스를 집어넣는 경우를 생각해보자. 이 경우 B 가 들어갈 만한 충분한 메모리 공간이 있지만 프로세스를 2 개로 나눌 수 없으므로 결국 메모리로 로드하지 못한다. (메모리 부족)
이러한 문제가 발생하는 이유는 세그먼트는 (논리적인 공간이기 때문에) 연속된 공간이고 나누어 질 수 없기 때문이다.
____________________
| Page 1 |
|____________________|
| Page 2 |
|____________________|
| .. | Segment ---> Process
|____________________|
| Page n |
|____________________|
| |
|____________________|
| |
|____________________|
Segment
|
페이지네이션 ('페이징' 이라고 하기도 한다) 이란 메모리를 고정된 길이의 n 개의 조각으로 나누는 것이다.
프로세스는 하나 이상의 페이지로 로드될 수 있다. 메모리가 해제되면 모든 페이지가 해제된다. (앞의 참고)
페이지네이션은 스와핑 (swapping) 이라고 하는 또하나의 중요한 목적을 위해서도 사용된다. 만약 페이지가 실제 메모리 상에 존재하지 않는다면 예외 (Exception) 를 발생시키고, 이는 커널이 메모리 상에 새로운 페이지를 찾게 한다. 이 메카니즘은 운영체제에서 실제 메모리가 허용하는 것보다 더 많은 응용 프로그램을 메모리 상에 로드할 수 있게 해준다.
____________________
Page X | Process Y |
|____________________|
| |
| WASTE |
| SPACE |
|____________________|
Pagination Problem
|
위의 그림을 보면 페이지네이션 정책의 문제점을 알 수 있을 것이다: 프로세스 Y 가 페이지 X 에 로드되는 경우, 하나의 페이지에 해당하는 전체 영역이 할당되므로 뒤쪽의 나머지 영역은 낭비된다.
세그먼테이션과 페이지네이션의 문제점을 해결하기 위해서 2 가지 정책을 혼합해서 사용한다.
| .. |
|____________________|
----->| Page 1 |
| |____________________|
| | .. |
____________________ | |____________________|
| | |---->| Page 2 |
| Segment X | ----| |____________________|
| | | | .. |
|____________________| | |____________________|
| | .. |
| |____________________|
|---->| Page 3 |
|____________________|
| .. |
|
(세그먼트 X 로 구분되는) 프로세스 X 는 3 부분으로 나누어지고 각각은 페이지로 로드된다.
이로 인해 다음과 같은 문제점이 해결된다:
-
세그먼테이션의 문제점: 메모리를 페이지 단위로 할당하고 해제하기 때문에 메모리 관리를 최적화된 방법으로 할 수 있다.
-
페이지네이션의 문제점: 오직 마지막 페이지 만이 낭비된다. 하지만 매우 작은 크기의 페이지를 사용하도록 결정할 수 있고 - 예를 들어 4096 바이트를 한 페이지로 설정한다면 최대 4096 * 태스크의 수 만큼의 바이트가 낭비될 것이다 - 페이지를 계층적으로 (2-3 단계로) 관리할 수 있다.
| | | |
| | Offset2 | Value |
| | /|\| |
Offset1 | |----- | | |
/|\ | | | | | |
| | | | \|/| |
| | | ------>| |
\|/ | | | |
Base Paging Address ---->| | | |
| ....... | | ....... |
| | | |
Hierarchical Paging
|
여기서는 startup_32: 라고 하는 레이블에서 시작되는 C 코드부터 살펴본다.
|startup_32:
|start_kernel
|lock_kernel
|trap_init
|init_IRQ
|sched_init
|softirq_init
|time_init
|console_init
|#ifdef CONFIG_MODULES
|init_modules
|#endif
|kmem_cache_init
|sti
|calibrate_delay
|mem_init
|kmem_cache_sizes_init
|pgtable_cache_init
|fork_init
|proc_caches_init
|vfs_caches_init
|buffer_init
|page_cache_init
|signals_init
|#ifdef CONFIG_PROC_FS
|proc_root_init
|#endif
|#if defined(CONFIG_SYSVIPC)
|ipc_init
|#endif
|check_bugs
|smp_init
|rest_init
|kernel_thread
|unlock_kernel
|cpu_idle
|
-
startup_32 [arch/i386/kernel/head.S]
-
start_kernel [init/main.c]
-
lock_kernel [include/asm/smplock.h]
-
trap_init [arch/i386/kernel/traps.c]
-
init_IRQ [arch/i386/kernel/i8259.c]
-
sched_init [kernel/sched.c]
-
softirq_init [kernel/softirq.c]
-
time_init [arch/i386/kernel/time.c]
-
console_init [drivers/char/tty_io.c]
-
init_modules [kernel/module.c]
-
kmem_cache_init [mm/slab.c]
-
sti [include/asm/system.h]
-
calibrate_delay [init/main.c]
-
mem_init [arch/i386/mm/init.c]
-
kmem_cache_sizes_init [mm/slab.c]
-
pgtable_cache_init [arch/i386/mm/init.c]
-
fork_init [kernel/fork.c]
-
proc_caches_init
-
vfs_caches_init [fs/dcache.c]
-
buffer_init [fs/buffer.c]
-
page_cache_init [mm/filemap.c]
-
signals_init [kernel/signal.c]
-
proc_root_init [fs/proc/root.c]
-
ipc_init [ipc/util.c]
-
check_bugs [include/asm/bugs.h]
-
smp_init [init/main.c]
-
rest_init
-
kernel_thread [arch/i386/kernel/process.c]
-
unlock_kernel [include/asm/smplock.h]
-
cpu_idle [arch/i386/kernel/process.c]
마지막 부분의 rest_init 라는 함수는 다음과 같은 일을 한다:
-
init 라는 커널 쓰레드를 시작시킨다.
-
kernel_unlock 을 호출한다.
-
실행할 프로세스가 아무 것도 없는 경우에 실행될 부분인 cpu_idle 루틴을 실행한다.
사실 start_kernel 함수는 절대 끝나지 않는다. 이 함수는 끝없이 cpu_idle 루틴을 실행시킨다.
다음은 첫번째 커널 쓰레드인 init 함수에 대한 설명이다:
|init
|lock_kernel
|do_basic_setup
|mtrr_init
|sysctl_init
|pci_init
|sock_init
|start_context_thread
|do_init_calls
|(*call())-> kswapd_init
|prepare_namespace
|free_initmem
|unlock_kernel
|execve
|
리눅스는 다른 운영체제들과 구분되는 다음과 같은 특징들을 가지고 있다:
-
페이지네이션만을 사용
-
소프트웨어 인터럽트 (softirq)
-
커널 쓰레드
-
커널 모듈
-
proc 디렉토리
위에서 열거한 4 번째와 5 번째 특징은 치명적인 커널 버그나 특정한 문제가 발생하였을 때 시스템을 리부팅하지 않고 (시스템 관리자가) 사용자 모드에서 문제를 해결하거나 시스템을 관리할 수 있는 막대한 유연성을 제공한다. 예를 들어 대형 서버에서 특정 부분을 수정할 필요가 있을 때 리부팅을 하지 않고 해결하기 위해서 커널 모듈을 이용할 수 있다.
리눅스에서는 각각의 태스크를 구분하기 위해 세그먼테이션을 사용하지 않고 페이지네이션을 사용한다. (모든 태스크는 오직 2 개의 세그먼트 (코드 세그먼트와 데이타 (스택) 세그먼트) 를 사용할 뿐이다.)
각각의 태스크는 자신만의 페이지 테이블을 사용하므로 서로 다른 태스크 간의 페이지 관련 오류는 절대 일어나지 않는다고 말할 수 있다. 어떤 경우에 있어서는 여러 태스크들이 하나의 페이지 테이블을 참조하기도 하는데, 공유 라이브러리와 같은 경우 (메모리를 절약하기 위해) 코드 부분을 공유하고 데이타는 각 태스크의 스택에 저장하는 방식을 사용한다.
리눅스 커널에서는 다음과 같은 오직 4 개의 세그먼트 만이 존재한다:
-
커널 코드 세그먼트 [0x10]
-
커널 데이타/스택 세그먼트 [0x18]
-
사용자 코드 세그먼트 [0x23]
-
사용자 데이타/스택 세그먼트 [0x2b]
목적 [세그먼트] 의 형태로 표현하였다.
인텔 CPU 의 경우, 다음과 같은 세그먼트 레지스터들이 사용된다:
그래서 모든 태스크는 코드 세그먼트로 0x23 을, 데이타/스택 세그먼트로 0x2b 를 사용한다.
리눅스에서는 하드웨어의 구조에 따라 3 단계의 페이지가 사용된다. 인텔 CPU 에서는 단지 2 단계의 페이지 만이 지원된다. 리눅스는 또한 Copy on Write 메카니즘을 지원한다. (더 자세한 정보는 을 참고)
대답은 매우 간단하다: 태스크들 간에 주소 충돌이 일어나지 않는 이유는 그것이 불가능하기 때문이다. 선형 주소를 물리 주소로 매핑하는 것은 페이지네이션 에 의해서 행해지므로 물리적인 페이지를 단일한 (univocal) 방법으로 할당할 필요가 없다.
그럴 필요가 없다. 페이지의 할당은 동적으로 이루어진다. 페이지는 오직 태스크가 페이지를 요청한 경우에만 필요하다. 그래서 크기 별로 정리된 이용 가능한 메모리 (페이지) 영역에서 원하는 크기에 해당하는 페이지를 선택한다. 페이지가 해제되면 단지 이용 가능한 페이지 리스트에 추가하면 된다.
커널 페이지에는 문제점이 하나 있다: 커널 페이지는 동적으로 할당되지만 할당되는 영역이 연속된 영역이라는 것을 보장할 수는 없다는 것이다. 왜냐하면 선형 커널 공간은 물리적인 커널 공간과 동일하기 때문이다..??
코드 세그먼트는 문제가 없다. 부트 코드는 부팅 시에 할당되고 (따라서 고정된 크기의 메모리 영역 만을 가진다) 모듈에서는 모듈 코드를 포함하는 메모리 영역 만을 할당한다.
실제적인 문제는 스택 세그먼트에서 나타나는데, 각각의 태스크들이 커널 스택 페이지를 사용하기 때문이다. 스택 세그먼트는 반드시 연속적인 영역에 할당되어야 하므로 (스택의 정의에 따라) 태스크의 스택 영역의 최대 크기를 정하게 되었다. 만약 이 크기를 넘어가게 되면 커널 모드 프로세스의 자료 구조를 덮어쓰게 되는 일이 벌어질 것이다.
커널의 구조는 이러한 문제점을 피하기 위해 다음과 같은 방식으로 함수를 사용한다:
-
재귀적인 함수 호출이 없다.
-
N 번 이상의 함수간 호출이 없다.
N 을 알고, 모든 커널 함수들의 정적 변수의 평균치를 알면 스택의 크기 제한을 추정할 수 있다.
이 문제점을 실제로 확인해 보고 싶다면, 내부적으로 자신을 재귀 호출하는 함수를 가지고 있는 모듈을 생성해 보면 된다. 이 모듈은 몇차례 수행된 후에 페이지 폴트 예외 핸들러에 의해서 중지될 것이다. (보통은 읽기 전용 페이지에 쓰기 접근 등의 이유로)
IRQ 가 발생하였을 때, 성능 향상을 위해 태스크 교환은 나중으로 미루어 진다. 몇몇가지 태스크 들은 (IRQ 를 처리한 후에 실행되며, TCP/IP 패킷을 구성하는 것 처럼 CPU 자원을 많이 필요로 하는 작업들) 큐에 넣어지며 스케줄링이 일어날 때 실행된다. (타임 슬라이스가 끝날 때)
최근 버전의 커널 (2.4.x) 에서는 소프트웨어 인터럽트 메카니즘은 kdoftirqd_CPUn 이라는 커널 쓰레드로 구현한다. n 은 커널 쓰레드가 실행되는 CPU 의 번호를 의미한다 (단일 CPU 시스템의 경우 ksoftirqd_CPU0 은 PID 3 번을 사용한다).
cpu_raise_softirq 은 큐에 들어있는 작업들을 관리하는 ksoftirqd_CPU0 커널 쓰레드를 깨우는 루틴이다.
|cpu_raise_softirq
|__cpu_raise_softirq
|wakeup_softirqd
|wake_up_process
|
-
cpu_raise_softirq [kernel/softirq.c]
-
__cpu_raise_softirq [include/linux/interrupt.h]
-
wakeup_softirq [kernel/softirq.c]
-
wake_up_process [kernel/sched.c]
__cpu_raise_softirq 루틴은 해당하는 소프트웨어 인터럽트가 발생하였다고 벡터 내의 비트를 설정한다.
wakeup_softirq 루틴은 ksoftirqd_CPU0 커널 쓰레드를 깨우기 위해 wakeup_process 을 사용한다.
TODO: 소프트웨어 인터럽트 메카니즘에 포함된 자료 구조를 설명
ksoftirqd_CPU0 커널 쓰레드가 깨어나면 큐에 들어있는 작업들을 수행할 것이다.
ksoftirqd_CPU0 의 코드는 다음과 같다 (부분 발췌):
for ( ; ; ) {
if (!softirq_pending(cpu))
schedule();
__set_current_state(TASK_RUNNING);
while (softirq_pending(cpu)) {
do_softirq();
if (current->need_resched)
schedule
}
__set_current_state(TASK_INTERRUPTIBLE)
}
|
리눅스가 모놀리틱 운영체제이지만, 시스템의 관리 (housekeeping) 작업을 위한 몇개의 커널 쓰레드 가 존재한다.
이러한 태스크들은 사용자 영역의 메모리를 사용하지 않고, 커널 영역의 메모리를 공유한다. 또한 다른 커널 영역의 코드와 비슷하게 높은 우선 순위를 가지고 실행된다. (i386 환경에서 RING0)
커널 쓰레드는 kernel_thread [arch/i386/kernel/process] 함수를 통해 생성된다. 이 함수는 어셈블리 부분에서 (fork 와 비슷한 시스템 콜인) clone [arch/i386/kernel/process.c] 시스템 콜을 호출한다:
int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
{
long retval, d0;
__asm__ __volatile__(
"movl %%esp,%%esi\n\t"
"int $0x80\n\t" /* Linux/i386 system call */
"cmpl %%esp,%%esi\n\t" /* child or parent? */
"je 1f\n\t" /* parent - jump */
/* Load the argument into eax, and push it. That way, it does
* not matter whether the called function is compiled with
* -mregparm or not. */
"movl %4,%%eax\n\t"
"pushl %%eax\n\t"
"call *%5\n\t" /* call fn */
"movl %3,%0\n\t" /* exit */
"int $0x80\n"
"1:\t"
:"=a" (retval), "=S" (d0)
:"0" (__NR_clone), "i" (__NR_exit),
"r" (arg), "r" (fn),
"b" (flags | CLONE_VM)
: "memory");
return retval;
}
|
이 함수가 한번 호출되면 매우 느린 자원 (스왑 혹은 USB 이벤트) 을 기다리고 있는 새로운 태스크 (보통 2, 3 처럼 매우 낮은 PID 를 가진다) 를 생성한 것이다. 이렇게 매우 느린 자원을 사용하는 이유는 태스크 교환에 따르는 오버헤드를 줄이기 위해서 이다.
아래는 (ps x 명령으로 알아본) 일반적인 커널 쓰레드의 리스트이다.
PID COMMAND
1 init
2 keventd
3 kswapd
4 kreclaimd
5 bdflush
6 kupdated
7 kacpid
67 khubd
|
init 커널 쓰레드는 부팅시에 최초로 생성되는 태스크이다. 이 태스크는 (/etc/inittab 을 참조하여) 다른 모든 사용자 모드 태스크 - 콘솔 데몬, tty 데몬, 네트워크 데몬 (rc 스크립트 참고) 등 - 을 호출한다.
kswapd 는 clone() [arch/i386/kernel/process.c] 에 의해 생성된다.
초기화 루틴은 다음과 같다:
|do_initcalls
|kswapd_init
|kernel_thread
|syscall fork (in assembler)
|
-
do_initcalls [init/main.c]
-
kswapd_init [mm/vmscan.c]
-
kernel_thread [arch/i386/kernel/process.c]
리눅스 커널 모듈은 실행 중에 추가할 수 있는 커널 모드에서 실행되는 코드의 일부분 (예를 들면, FS (파일 시스템), 네트워크, 하드웨어 드라이버 등) 을 말한다.
리눅스의 핵심 부분 - 프로세스 스케줄링, 인터럽트 관리, 네트워크의 핵심적인 부분 - 들은 모듈화될 수 없다.
/lib/modules/커널버전/ 디렉토리에 시스템에 설치된 모듈들을 찾아볼 수 있다.
모듈을 로드하기 위해서는 다음과 같은 명령어를 사용한다:
insmod 모듈이름 parameters
예 4. insmod ne io=0x300 irq=9
참고: 커널 몇가지 파라미터들을 자동으로 찾아주기를 원한다면 (예를 들면 PCI 드라이버를 사용하는 경우나, /etc/conf.modules 안에 파라미터를 적어둔 경우) insmod 대신에 modprobe 를 사용할 수 있다.
모듈은 언로딩하기 위해서는 다음과 같은 명령어를 사용한다:
rmmod 모듈이름
모듈은 항상 다음과 같은 내용을 포함한다:
-
insmod (혹은 modprobe) 시에 실행되는 init_module 함수
-
rmmod 시에 실행되는 cleanup_module 함수
만약 위의 두 함수가 모듈내에 존재하지 않는다면, 어떤 함수가 이러한 역할 (init, exit) 을 할 것인지를 나타내기 위해 다음과 같은 2 개의 매크로를 추가해야 한다.
-
module_init(함수이름)
-
module_exit(함수이름)
참고: 모듈에서는 오직 (EXPORT_SYMBOL 매크로를 이용하여) 외부로 공개된 커널 변수만을 볼 수 있다.
// kernel sources side
void (*foo_function_pointer)(void *);
if (foo_function_pointer)
(foo_function_pointer)(parameter);
|
// module side
extern void (*foo_function_pointer)(void *);
void my_function(void *parameter) {
//My code
}
int init_module() {
foo_function_pointer = my_function;
}
int cleanup_module() {
foo_function_pointer = NULL;
}
|
이 간단한 팁은 오직 모듈이 로드되었을 때만 my_function 루틴을 실행하도록 하기 때문에 커널에 높은 유연성을 주게 된다. 이 함수 내에서는 원하는 어떤 행동이라도 수행할 수 있다: 예를 들어 rshape 모듈은 네트워크로부터 들어오는 입력 트래픽의 BandWidth 를 조절하는 것과 같은 역할을 한다.
전체 모듈 메카니즘은 고맙게도 head list (원하는 만큼 리스트를 확장할 수 있게 허용) 와 같은 전역 변수를 모듈에 공개 (export) 하는 것이 가능하다. 전형적인 예로는 파일 시스템, Generic devices (문자, 블럭, 네크워크, 전화 연결) 등이 있다. 그리고 커널이 모듈을 사용할 수 있도록 준비해야 한다: 특정한 경우에 있어서는 가능한 표준에 맞게 다른 구조 (infrastructure) 들을 생성해야 한다. (최근에 생성된 전화연결 장치와 같이)
proc 파일 시스템은 /proc 디렉토리에 있으며, 커널과 직접 대화하는 것이 허용된 특수한 디렉토리이다.
리눅스는 커널과의 직접적인 통신을 지원하기 위해 proc 디렉토리를 사용한다: 이것은 많은 경우에 유용하다 - 예를 들어 메인 프로세스의 자료 구조를 보고 싶다거나 특정한 하나의 네트워크 인터페이스에만 proxy-arp 기능을 활성화하는 경우, 최대 쓰레드의 갯수를 변경하고 싶은 경우, 혹은 ISA 나 PCI 와 같은 특정 버스의 상태를 디버깅하는 경우에 있어서 어떤 카드가 설치되어 있고, 어떤 I/O address 를 사용하며, 할당된 IRQ 가 어떤 것이 있는지를 알고 싶은 경우 등이 있겠다.
|-- bus
| |-- pci
| | |-- 00
| | | |-- 00.0
| | | |-- 01.0
| | | |-- 07.0
| | | |-- 07.1
| | | |-- 07.2
| | | |-- 07.3
| | | |-- 07.4
| | | |-- 07.5
| | | |-- 09.0
| | | |-- 0a.0
| | | `-- 0f.0
| | |-- 01
| | | `-- 00.0
| | `-- devices
| `-- usb
|-- cmdline
|-- cpuinfo
|-- devices
|-- dma
|-- dri
| `-- 0
| |-- bufs
| |-- clients
| |-- mem
| |-- name
| |-- queues
| |-- vm
| `-- vma
|-- driver
|-- execdomains
|-- filesystems
|-- fs
|-- ide
| |-- drivers
| |-- hda -> ide0/hda
| |-- hdc -> ide1/hdc
| |-- ide0
| | |-- channel
| | |-- config
| | |-- hda
| | | |-- cache
| | | |-- capacity
| | | |-- driver
| | | |-- geometry
| | | |-- identify
| | | |-- media
| | | |-- model
| | | |-- settings
| | | |-- smart_thresholds
| | | `-- smart_values
| | |-- mate
| | `-- model
| |-- ide1
| | |-- channel
| | |-- config
| | |-- hdc
| | | |-- capacity
| | | |-- driver
| | | |-- identify
| | | |-- media
| | | |-- model
| | | `-- settings
| | |-- mate
| | `-- model
| `-- via
|-- interrupts
|-- iomem
|-- ioports
|-- irq
| |-- 0
| |-- 1
| |-- 10
| |-- 11
| |-- 12
| |-- 13
| |-- 14
| |-- 15
| |-- 2
| |-- 3
| |-- 4
| |-- 5
| |-- 6
| |-- 7
| |-- 8
| |-- 9
| `-- prof_cpu_mask
|-- kcore
|-- kmsg
|-- ksyms
|-- loadavg
|-- locks
|-- meminfo
|-- misc
|-- modules
|-- mounts
|-- mtrr
|-- net
| |-- arp
| |-- dev
| |-- dev_mcast
| |-- ip_fwchains
| |-- ip_fwnames
| |-- ip_masquerade
| |-- netlink
| |-- netstat
| |-- packet
| |-- psched
| |-- raw
| |-- route
| |-- rt_acct
| |-- rt_cache
| |-- rt_cache_stat
| |-- snmp
| |-- sockstat
| |-- softnet_stat
| |-- tcp
| |-- udp
| |-- unix
| `-- wireless
|-- partitions
|-- pci
|-- scsi
| |-- ide-scsi
| | `-- 0
| `-- scsi
|-- self -> 2069
|-- slabinfo
|-- stat
|-- swaps
|-- sys
| |-- abi
| | |-- defhandler_coff
| | |-- defhandler_elf
| | |-- defhandler_lcall7
| | |-- defhandler_libcso
| | |-- fake_utsname
| | `-- trace
| |-- debug
| |-- dev
| | |-- cdrom
| | | |-- autoclose
| | | |-- autoeject
| | | |-- check_media
| | | |-- debug
| | | |-- info
| | | `-- lock
| | `-- parport
| | |-- default
| | | |-- spintime
| | | `-- timeslice
| | `-- parport0
| | |-- autoprobe
| | |-- autoprobe0
| | |-- autoprobe1
| | |-- autoprobe2
| | |-- autoprobe3
| | |-- base-addr
| | |-- devices
| | | |-- active
| | | `-- lp
| | | `-- timeslice
| | |-- dma
| | |-- irq
| | |-- modes
| | `-- spintime
| |-- fs
| | |-- binfmt_misc
| | |-- dentry-state
| | |-- dir-notify-enable
| | |-- dquot-nr
| | |-- file-max
| | |-- file-nr
| | |-- inode-nr
| | |-- inode-state
| | |-- jbd-debug
| | |-- lease-break-time
| | |-- leases-enable
| | |-- overflowgid
| | `-- overflowuid
| |-- kernel
| | |-- acct
| | |-- cad_pid
| | |-- cap-bound
| | |-- core_uses_pid
| | |-- ctrl-alt-del
| | |-- domainname
| | |-- hostname
| | |-- modprobe
| | |-- msgmax
| | |-- msgmnb
| | |-- msgmni
| | |-- osrelease
| | |-- ostype
| | |-- overflowgid
| | |-- overflowuid
| | |-- panic
| | |-- printk
| | |-- random
| | | |-- boot_id
| | | |-- entropy_avail
| | | |-- poolsize
| | | |-- read_wakeup_threshold
| | | |-- uuid
| | | `-- write_wakeup_threshold
| | |-- rtsig-max
| | |-- rtsig-nr
| | |-- sem
| | |-- shmall
| | |-- shmmax
| | |-- shmmni
| | |-- sysrq
| | |-- tainted
| | |-- threads-max
| | `-- version
| |-- net
| | |-- 802
| | |-- core
| | | |-- hot_list_length
| | | |-- lo_cong
| | | |-- message_burst
| | | |-- message_cost
| | | |-- mod_cong
| | | |-- netdev_max_backlog
| | | |-- no_cong
| | | |-- no_cong_thresh
| | | |-- optmem_max
| | | |-- rmem_default
| | | |-- rmem_max
| | | |-- wmem_default
| | | `-- wmem_max
| | |-- ethernet
| | |-- ipv4
| | | |-- conf
| | | | |-- all
| | | | | |-- accept_redirects
| | | | | |-- accept_source_route
| | | | | |-- arp_filter
| | | | | |-- bootp_relay
| | | | | |-- forwarding
| | | | | |-- log_martians
| | | | | |-- mc_forwarding
| | | | | |-- proxy_arp
| | | | | |-- rp_filter
| | | | | |-- secure_redirects
| | | | | |-- send_redirects
| | | | | |-- shared_media
| | | | | `-- tag
| | | | |-- default
| | | | | |-- accept_redirects
| | | | | |-- accept_source_route
| | | | | |-- arp_filter
| | | | | |-- bootp_relay
| | | | | |-- forwarding
| | | | | |-- log_martians
| | | | | |-- mc_forwarding
| | | | | |-- proxy_arp
| | | | | |-- rp_filter
| | | | | |-- secure_redirects
| | | | | |-- send_redirects
| | | | | |-- shared_media
| | | | | `-- tag
| | | | |-- eth0
| | | | | |-- accept_redirects
| | | | | |-- accept_source_route
| | | | | |-- arp_filter
| | | | | |-- bootp_relay
| | | | | |-- forwarding
| | | | | |-- log_martians
| | | | | |-- mc_forwarding
| | | | | |-- proxy_arp
| | | | | |-- rp_filter
| | | | | |-- secure_redirects
| | | | | |-- send_redirects
| | | | | |-- shared_media
| | | | | `-- tag
| | | | |-- eth1
| | | | | |-- accept_redirects
| | | | | |-- accept_source_route
| | | | | |-- arp_filter
| | | | | |-- bootp_relay
| | | | | |-- forwarding
| | | | | |-- log_martians
| | | | | |- mc_forwarding
| | | | | |-- proxy_arp
| | | | | |-- rp_filter
| | | | | |-- secure_redirects
| | | | | |-- send_redirects
| | | | | |-- shared_media
| | | | | `-- tag
| | | | `-- lo
| | | | |-- accept_redirects
| | | | |-- accept_source_route
| | | | |-- arp_filter
| | | | |-- bootp_relay
| | | | |-- forwarding
| | | | |-- log_martians
| | | | |-- mc_forwarding
| | | | |-- proxy_arp
| | | | |-- rp_filter
| | | | |-- secure_redirects
| | | | |-- send_redirects
| | | | |-- shared_media
| | | | `-- tag
| | | |-- icmp_echo_ignore_all
| | | |-- icmp_echo_ignore_broadcasts
| | | |-- icmp_ignore_bogus_error_responses
| | | |-- icmp_ratelimit
| | | |-- icmp_ratemask
| | | |-- inet_peer_gc_maxtime
| | | |-- inet_peer_gc_mintime
| | | |-- inet_peer_maxttl
| | | |-- inet_peer_minttl
| | | |-- inet_peer_threshold
| | | |-- ip_autoconfig
| | | |-- ip_conntrack_max
| | | |-- ip_default_ttl
| | | |-- ip_dynaddr
| | | |-- ip_forward
| | | |-- ip_local_port_range
| | | |-- ip_no_pmtu_disc
| | | |-- ip_nonlocal_bind
| | | |-- ipfrag_high_thresh
| | | |-- ipfrag_low_thresh
| | | |-- ipfrag_time
| | | |-- neigh
| | | | |-- default
| | | | | |-- anycast_delay
| | | | | |-- app_solicit
| | | | | |-- base_reachable_time
| | | | | |-- delay_first_probe_time
| | | | | |-- gc_interval
| | | | | |-- gc_stale_time
| | | | | |-- gc_thresh1
| | | | | |-- gc_thresh2
| | | | | |-- gc_thresh3
| | | | | |-- locktime
| | | | | |-- mcast_solicit
| | | | | |-- proxy_delay
| | | | | |-- proxy_qlen
| | | | | |-- retrans_time
| | | | | |-- ucast_solicit
| | | | | `-- unres_qlen
| | | | |-- eth0
| | | | | |-- anycast_delay
| | | | | |-- app_solicit
| | | | | |-- base_reachable_time
| | | | | |-- delay_first_probe_time
| | | | | |-- gc_stale_time
| | | | | |-- locktime
| | | | | |-- mcast_solicit
| | | | | |-- proxy_delay
| | | | | |-- proxy_qlen
| | | | | |-- retrans_time
| | | | | |-- ucast_solicit
| | | | | `-- unres_qlen
| | | | |-- eth1
| | | | | |-- anycast_delay
| | | | | |-- app_solicit
| | | | | |-- base_reachable_time
| | | | | |-- delay_first_probe_time
| | | | | |-- gc_stale_time
| | | | | |-- locktime
| | | | | |-- mcast_solicit
| | | | | |-- proxy_delay
| | | | | |-- proxy_qlen
| | | | | |-- retrans_time
| | | | | |-- ucast_solicit
| | | | | `-- unres_qlen
| | | | `-- lo
| | | | |-- anycast_delay
| | | | |-- app_solicit
| | | | |-- base_reachable_time
| | | | |-- delay_first_probe_time
| | | | |-- gc_stale_time
| | | | |-- locktime
| | | | |-- mcast_solicit
| | | | |-- proxy_delay
| | | | |-- proxy_qlen
| | | | |-- retrans_time
| | | | |-- ucast_solicit
| | | | `-- unres_qlen
| | | |-- route
| | | | |-- error_burst
| | | | |-- error_cost
| | | | |-- flush
| | | | |-- gc_elasticity
| | | | |-- gc_interval
| | | | |-- gc_min_interval
| | | | |-- gc_thresh
| | | | |-- gc_timeout
| | | | |-- max_delay
| | | | |-- max_size
| | | | |-- min_adv_mss
| | | | |-- min_delay
| | | | |-- min_pmtu
| | | | |-- mtu_expres
| | | | |-- redirect_load
| | | | |-- redirect_number
| | | | `-- redirect_silence
| | | |-- tcp_abort_on_overflow
| | | |-- tcp_adv_win_scale
| | | |-- tcp_app_win
| | | |-- tcp_dsack
| | | |-- tcp_ecn
| | | |-- tcp_fack
| | | |-- tcp_fin_timeout
| | | |-- tcp_keepalive_intvl
| | | |-- tcp_keepalive_probes
| | | |-- tcp_keepalive_time
| | | |-- tcp_max_orphans
| | | |-- tcp_max_syn_backlog
| | | |-- tcp_max_tw_buckets
| | | |-- tcp_mem
| | | |-- tcp_orphan_retries
| | | |-- tcp_reordering
| | | |-- tcp_retrans_collapse
| | | |-- tcp_retries1
| | | |-- tcp_retries2
| | | |-- tcp_rfc1337
| | | |-- tcp_rmem
| | | |-- tcp_sack
| | | |-- tcp_stdurg
| | | |-- tcp_syn_retries
| | | |-- tcp_synack_retries
| | | |-- tcp_syncookies
| | | |-- tcp_timestamps
| | | |-- tcp_tw_recycle
| | | |-- tcp_window_scaling
| | | `-- tcp_wmem
| | `-- unix
| | `-- max_dgram_qlen
| |-- proc
| `-- vm
| |-- bdflush
| |-- kswapd
| |-- max-readahead
| |-- min-readahead
| |-- overcommit_memory
| |-- page-cluster
| `-- pagetable_cache
|-- sysvipc
| |-- msg
| |-- sem
| `-- shm
|-- tty
| |-- driver
| | `-- serial
| |-- drivers
| |-- ldisc
| `-- ldiscs
|-- uptime
`-- version
|
이 디렉토리에는 모든 태스크에 관한 정보가 들어있다. (각 디렉토리의 이름은 태스크의 PID 에 해당하는 숫자이고 이를 이용하여 태스크에 대한 모든 정보 - 실행 파일의 경로라든지 메모리 사용량 등 - 를 볼 수 있다)
흥미로운 점은 이러한 커널의 정보 들을 단지 볼 수만 있는 것이 아니라 (태스크의 정보 혹은 TCP/IP 스택을 활성화하는 네트워크 옵션에 관한 사항들을 보는 것) 몇몇 정보들은 수정할 수도 있다는 것이다. 일반적으로 이러한 것들은 /proc/sys 디렉토리 아래에 있다.
/proc/sys/
acpi
dev
debug
fs
proc
net
vm
kernel
|
다음은 매우 중요하고 잘 알려진 수정할 수 있는 커널 정보들이다:
overflowgid
overflowuid
random
threads-max // Max number of threads, typically 16384
sysrq // kernel hack: you can view instant register values and more
sem
msgmnb
msgmni
msgmax
shmmni
shmall
shmmax
rtsig-max
rtsig-nr
modprobe // modprobe file location
printk
ctrl-alt-del
cap-bound
panic
domainname // domain name of your Linux box
hostname // host name of your Linux box
version // date info about kernel compilation
osrelease // kernel version (i.e. 2.4.5)
ostype // Linux!
|
이것은 proc 의 하위 디렉토리 중에서 가장 유용한 디렉토리일 것이다. 여기서는 커널의 네트워크 설정에 대한 매우 중요한 부분들을 변경할 수 있다.
core
ipv4
ipv6
unix
ethernet
802
|
아래의 리스트는 netdev_max_backlog - 네트워크 패킷의 전체 갯수 (보통 300) - 와 같은 일반적인 네트워크 설정을 보여준다. 이 값은 패킷을 받을 때 네트워크의 BandWidth 를 제한할 수 있다. 리눅스는 버퍼를 비우기 위해 스케줄링이 일어날 때 까지 기다려야 한다 (bottom half 메카니즘에 의해 처리). 1000/HZ ms 일 때
300 * 100 = 30 000
packets HZ(Timeslice freq) packets/s
30 000 * 1000 = 30 M
packets average (Bytes/packet) throughput Bytes/s
|
만약 더 높은 throughput 을 원한다면 netdev_max_backlog 을 다음과 같이 증가시킬 수 있다:
echo 4000 > /proc/sys/net/core/netdev_max_backlog
참고: HZ 값에 주의하기 바란다: (alpha 나 arm-tbox 같은) 특정 환경에서는 이 값이 1000 으로 설정되어 있기 때문에 평균 300 MBytes/sec 의 throughput 이 나온다.
ip_forward 값은 리눅스 박스의 IP 포워딩을 활성화하거나 비활성화 시키는 역할을 한다. 이것은 모든 장치에 대한 일반적인 설정이고, 각각의 장치를 선택하여 명시할 수도 있다.
개인적인 생각으로는 이 디렉토리가 /proc 중에서 가장 유용한 곳이라고 생각한다. 왜냐하면 이곳에서 네트워크 설정을 조금 변경하여 무선 네트워크를 지원하도록 할 수 있기 때문이다. (자세한 내용은 Wireless-HOWTO 문서를 참고하기 바란다)
이를 이용하는 예제로는 다음과 같은 것들이 있다:
이 절에서는 리눅스에서 멀티태스킹 환경을 관리하는 메카니즘과 자료 구조에 대해서 분석해 볼 것이다.
리눅스의 태스크는 다음 중의 한가지 상태를 가진다 ([include/linux.h] 참고):
-
TASK_RUNNING, 이 상태는 태스크가 Ready 리스트 에 들어있음을 말한다.
-
TASK_INTERRUPTIBLE, 태스크는 시그널이나 자원을 기다리는 중이다. (sleep)
-
TASK_UNINTERRUPTIBLE, 태스크는 자원을 기다리고 있으며 (sleep), 같은 대기 큐 에 들어있다.
-
TASK_ZOMBIE, 부모가 없는 자식 태스크
-
TASK_STOPPED, 태스크는 디버깅 중이다.
______________ CPU Available ______________
| | ----------------> | |
| TASK_RUNNING | | Real Running |
|______________| ---------------- |______________|
CPU Busy
| /|\
Waiting for | | Resource
Resource | | Available
\|/ |
______________________
| |
| TASK_INTERRUPTIBLE / |
| TASK-UNINTERRUPTIBLE |
|______________________|
Main Multitasking Flow
|
매 10 ms 마다 (HZ 값의 설정에 따라 다를 수 있음) 멀티태스킹 환경을 지원하도록 IRQ0 이 발생한다. 이 신호는 1.19318 MHz 의 주파수를 가지는 PIT 8253 클럭에 연결된 PIC 8259 (i386 이상에서) 칩에서 발생된다.
_____ ______ ______
| CPU |------| 8259 |------| 8253 |
|_____| IRQ0 |______| |___/|\|
|_____ CLK 1.193.180 MHz
|
// From include/asm/param.h
#ifndef HZ
#define HZ 100
#endif
// From include/asm/timex.h
#define CLOCK_TICK_RATE 1193180 /* Underlying HZ */
// From include/linux/timex.h
#define LATCH ((CLOCK_TICK_RATE + HZ/2) / HZ) /* For divider */
// From arch/i386/kernel/i8259.c
outb_p(0x34,0x43); /* binary, mode 2, LSB/MSB, ch 0 */
outb_p(LATCH 0xff , 0x40); /* LSB */
outb(LATCH >> 8 , 0x40); /* MSB */
|
그래서 8253 PIT (Programmable Inteval Timer) 를 프로그래밍할 때 HZ 값이 100 인 경우 (기본값) LATCH 값을 11931.8 (1193180 / HZ) 로 설정한다. LATCH 값은 주파수를 결정하는 요소가 된다. (frequence divisor factor)
LATCH 를 11931.8 로 설정하는 것은 8253 의 출력값이 1193180/11931.8 = 100 HZ 의 주파수를 가지도록 한다. 따라서 주기는 10 ms 가 된다.
즉, 타임 슬라이스 값은 1/HZ 이다.
각 타임 슬라이스 마다 일시적으로 현재 프로세스의 실행을 중지하고 (태스크 스위칭 없이) 몇가지 부수적인 일들을 처리한 후에 다시 이전의 프로세스로 돌아오게 된다.
Linux Timer IRQ
IRQ 0 [Timer]
|
\|/
|IRQ0x00_interrupt // 포장 (wrapper) IRQ 핸들러
|SAVE_ALL ---
|do_IRQ | 포장 함수
|handle_IRQ_event ---
|handler() -> timer_interrupt // 등록된 IRQ 0 핸들러
|do_timer_interrupt
|do_timer
|jiffies++;
|update_process_times
|if (--counter = 0) { // 프로세스의 타임 슬라이스가 다 된 경우
|counter = 0; // counter 값을 지우고
|need_resched = 1; // 스케줄링을 요청함
|}
|do_softirq
|while (need_resched) { // 필요한 경우
|schedule // 프로세스를 스케줄링
|handle_softirq
|}
|RESTORE_ALL
|
각 함수들은 아래와 같이 찾아볼 수 있다:
-
IRQ0x00_interrupt, SAVE_ALL [include/asm/hw_irq.h]
-
IRQ0x00_interrupt, SAVE_ALL [include/asm/hw_irq.h]
-
timer_interrupt, do_timer_interrupt [arch/i386/kernel/time.c]
-
do_timer, update_process_times [kernel/timer.c]
-
do_softirq [kernel/soft_irq.c]
-
RESTORE_ALL, while loop [arch/i386/kernel/entry.S]
참고: -
IRQ0x00_interrupt 함수는 (다른 IRQ0xXY_interrupt 함수처럼) IDT (Interrupt Descriptor Table, 리얼 모드의 Interrupt Vector Table 과 같다. 11 장 참고) 에서 직접 가리키고 있으므로, 프로세서로 들어오는 모든 인터럽트는 IRQ0x#NR_interrupt 함수에 의해 처리된다. (여기서 #NR 은 인터럽트 번호를 의미) 그래서 여기에서는 이런 함수들은 포장 IRQ 핸들러 (wrapper irq handler) 라고 부른다.
-
do_IRQ 이나 handle_IRQ_event 와 같은 포장 함수들이 실행된다. [arch/i386/kernel/irq.c]
-
그 이후에는 이전에 request_irq [arch/i386/kernel/irq.c] 에서 등록된 (handler() 로 참조되는) 공식적인 IRQ 루틴 으로 제어가 넘어간다. 이 경우에는 timer_interrupt [arch/i386/kernel/time.c] 가 된다.
-
timer_interrupt [arch/i386/kernel/time.c] 가 실행된다.
-
제어는 어셈블리 루틴으로 넘어간다. [arch/i386/kernel/entry.S]
설명:
멀티태스킹을 관리하기 위해 리눅스에서는 (다른 유닉스에서와 같이) counter 이라는 변수를 두어서 태스크가 CPU 를 얼만큼 사용했는지를 기록해 둔다. 그래서 매 IRQ 0 에서 이 값을 감소시키고 (4 번 부분에 해당), counter 값이 0 이 되면 태스크 스위칭이 일어나도록 한다. (4 번에서 need_resched 값을 1 로 설정하고, 5 번에서 resched 값에 따라 schedule [kernel/sched.c] 이 실행된다)
스케줄러는 주어진 특정 시간에서 실행되어야 할 태스크를 선택하는 부분의 코드를 말한다.
실행되고 있는 태스크를 교체해야 하는 경우에 그 후보가 될 태스크를 선택한다. 아래는 schedule 함수이다. [kernel/sched.c]
|schedule
|do_softirq // 이전에 걸린 soft-IRQ 처리
|for each task
|calculate counter
|prepare_to__switch // 태스크 스위칭을 위한 환경 설정
|switch_mm // 메모리 환경 변경 (CR3 레지스터 값 수정)
|switch_to (assembler)
|SAVE ESP
|RESTORE future_ESP
|SAVE EIP
|push future_EIP *** 함수 호출을 한 것 처럼 파라미터 설정
|jmp __switch_to (TSS 에 관련된 작업을 수행)
|__switch_to()
..
|ret *** future_EIP 가 가리키는 곳으로 복귀
new_task
|
전통적인 유닉스에서는 (장치로 부터) IRQ 가 발생했을 때, 장치가 요청한 태스크를 처리하기 위해 태스크 스위칭 을 수행하였다.
리눅스에서는 성능을 향상시키기 위해 긴급하지 않은 작업은 뒤로 미루어 더 빠른 이벤트 처리를 할 수 있도록 한다.
이 기능은 커널 버전 1.x 에서부터 하반부 (Bottom Half - BH) 에 의해 수행되어 졌다. IRQ 핸들러에서는 (나중에 - 스케줄링시 - 수행되도록) 하반부로 표시한다.
최신의 커널 버전에서는 좀 더 동적이고 멀티 프로세서 환경을 지원하는 소작업 (Tasklet) 이라는 개념을 도입하였다.
하반부는 다음과 같은 형태가 될 것이다:
-
선언 (Declaration)
-
표시 (Mark)
-
실행 (Execution)
#define DECLARE_TASK_QUEUE(q) LIST_HEAD(q)
#define LIST_HEAD(name) \
struct list_head name = LIST_HEAD_INIT(name)
struct list_head {
struct list_head *next, *prev;
};
#define LIST_HEAD_INIT(name) { (name), (name) }
|
DECLARE_TASK_QUEUE [include/linux/tqueue.h, include/linux/list.h]
|
DECLARE_TASK_QUEUE(q) 매크로는 태스크 큐를 관리하는 q 라는 구조체를 선언하는데 사용된다.
아래는 mark_bh 함수에 대한 함수간 호출 분석이다 [include/linux/interrupt.h]:
|mark_bh(NUMBER)
|tasklet_hi_schedule(bh_task_vec + NUMBER)
|insert into tasklet_hi_vec
|__cpu_raise_softirq(HI_SOFTIRQ)
|soft_active |= (1 HI_SOFTIRQ)
''mark_bh''[include/linux/interrupt.h]
|
do_IRQ 함수에서 아래와 같은 부분이 호출되는 것을 볼 수 있을 것이다 [arch/i386/kernel/irq.c]:
|do_softirq
|h->action(h)-> softirq_vec[TASKLET_SOFTIRQ]->action -> tasklet_action
|tasklet_vec[0].list->func
|
h->action(h) 은 이전에 큐에 들어가 있던 함수이다.
set_intr_gate
set_trap_gate
set_task_gate (사용되지 않음)
(*interrupt)[NR_IRQS](void) = { IRQ0x00_interrupt, IRQ0x01_interrupt, ..}
NR_IRQS = 224 [kernel 2.4.2]
여기서는 리눅스 커널이 수행중인 태스크를 다른 태스크로 교체하는 것을 살펴볼 것이다.
태스크 스위칭은 다음과 같은 많은 경우에서 필요하다:
-
타임 슬라이스가 끝난 경우, 다른 태스크를 실행해야 한다.
-
태스크가 자원을 사용하려는 경우 이 자원을 이용할 수 있을 때까지 잠들게 된다. 이 때에도 다른 태스크를 실행해야 한다.
-
태스크가 파이프를 기다리고 있는 경우, 파이프에 쓰기 연산을 수행할 다른 태스크를 실행해야 한다.
TASK SWITCHING TRICK
#define switch_to(prev,next,last) do { \
asm volatile("pushl %%esi\n\t" \
"pushl %%edi\n\t" \
"pushl %%ebp\n\t" \
"movl %%esp,%0\n\t" /* save ESP */ \
"movl %3,%%esp\n\t" /* restore ESP */ \
"movl $1f,%1\n\t" /* save EIP */ \
"pushl %4\n\t" /* restore EIP */ \
"jmp __switch_to\n" \
"1:\t" \
"popl %%ebp\n\t" \
"popl %%edi\n\t" \
"popl %%esi\n\t" \
:"=m" (prev->thread.esp),"=m" (prev->thread.eip), \
"=b" (last) \
:"m" (next->thread.esp),"m" (next->thread.eip), \
"a" (prev), "d" (next), \
"b" (prev)); \
} while (0)
|
여기에는 다음과 같은 트릭이 존재한다:
-
push %4 를 통해 스택에 future_EIP 를 넣는다.
-
jmp __switch_to 는 __switch_to 함수를 실행한다. 하지만 call 명령을 통해 실행한 것이 아니기 때문에 실행된 뒤에는 위에서 설정한 future_EIP 부분으로 리턴될 것이다. (따라서 새로운 태스크가 실행된다)
U S E R M O D E K E R N E L M O D E
| | | | | | | |
| | | | Timer | | | |
| | | Normal | IRQ | | | |
| | | Exec |------>|Timer_Int.| | |
| | | | | | .. | | |
| | | \|/ | |schedule()| | Task1 Ret|
| | | | |_switch_to|-- | Address |
|__________| |__________| | | | | |
| | |S | |
Task1 Data/Stack Task1 Code | | |w | |
| | T|i | |
| | a|t | |
| | | | | | s|c | |
| | | | Timer | | k|h | |
| | | Normal | IRQ | | |i | |
| | | Exec |------>|Timer_Int.| |n | |
| | | | | | .. | |g | |
| | | \|/ | |schedule()| | | Task2 Ret|
| | | | |_switch_to|-- | Address |
|__________| |__________| |__________| |__________|
Task2 Data/Stack Task2 Code Kernel Code Kernel Data/Stack
|
fork 는 새로운 태스크를 생성하기 위해 사용된다. Task Parent 에서 시작하여 Task Child 로 많은 자료구조를 복사한다.
| |
| .. |
Task Parent | |
| | | |
| fork |---------->| CREATE |
| | /| NEW |
|_________| / | TASK |
/ | |
--- / | |
--- / | .. |
/ | |
Task Child /
| | /
| fork |-/
| |
|_________|
Fork SysCall
|
새로 생성된 태스크 (Task Child) 는 그 부모 태스크 (Task Parent) 와 거의 같지만, 다음과 같은 차이점이 있다:
-
명백한 차이점으로는 PID 값이 다르다.
-
자식 태스크에서는 fork() 함수가 0 을 리턴하지만, 부모 태스크에서는 자식 태스크의 PID 값은 리턴한다. (사용자 모드에서 이를 이용해 서로를 구별한다)
-
자식 태스크의 모든 데이타 페이지는 (부모 태스크에서 자신의 페이지에 WRITE 권한을 가지도록 설정된 데 반해) WRITE 권한 없이 READ + EXECUTE 권한으로 설정되어 진다. 그래서 쓰기 연산이 요청되면 Page Fault 예외가 발생되어 새로운 독립적인 페이지를 생성하게 된다. 이러한 메카니즘을 Copy on Write 라고 부른다. (더 자세한 사항은 에서 설명한다)
|sys_fork
|do_fork
|alloc_task_struct
|__get_free_pages
|p->state = TASK_UNINTERRUPTIBLE
|copy_flags
|p->pid = get_pid
|copy_files
|copy_fs
|copy_sighand
|copy_mm // CopyOnWrite 메카니즘을 관리 (I part)
|allocate_mm
|mm_init
|pgd_alloc -> get_pgd_fast
|get_pgd_slow
|dup_mmap
|copy_page_range
|ptep_set_wrprotect
|clear_bit // 페이지를 read-only 로 설정
|copy_segments // For LDT
|copy_thread
|childregs->eax = 0
|p->thread.esp = childregs // 자식 태스크에서 0 을 리턴하도록 설정
|p->thread.eip = ret_from_fork // 자식 태스크가 수행될 시작 부분 설정
|retval = p->pid // 부모 태스크는 자식 태스크의 pid 를 리턴하도록 설정
|SET_LINKS // 태스크를 리스트 포인터에 삽입
|nr_threads++ // 전역 변수
|wake_up_process(p) // 새로 생성된 자식 태스크를 깨움
|return retval
fork ICA
|
-
sys_fork [arch/i386/kernel/process.c]
-
do_fork [kernel/fork.c]
-
alloc_task_struct [include/asm/processor.c]
-
__get_free_pages [mm/page_alloc.c]
-
get_pid [kernel/fork.c]
-
copy_files
-
copy_fs
-
copy_sighand
-
copy_mm
-
allocate_mm
-
mm_init
-
pgd_alloc -> get_pgd_fast [include/asm/pgalloc.h]
-
get_pgd_slow
-
dup_mmap [kernel/fork.c]
-
copy_page_range [mm/memory.c]
-
ptep_set_wrprotect [include/asm/pgtable.h]
-
clear_bit [include/asm/bitops.h]
-
copy_segments [arch/i386/kernel/process.c]
-
copy_thread
-
SET_LINKS [include/linux/sched.h]
-
wake_up_process [kernel/sched.c]
리눅스에서는 다음과 같은 방법으로 Copy on Write 를 구현한다:
-
쓰기 연산이 일어날 때 Page Falut 가 일어나도록 복사된 모든 페이지를 read-only 로 표시한다.
-
Page Fault 핸들러에서 새로운 페이지를 생성한다.
| Page
| Fault
| Exception
|
|
-----------> |do_page_fault
|handle_mm_fault
|handle_pte_fault
|do_wp_page
|alloc_page // 새로운 페이지 할당
|break_cow
|copy_cow_page // 이전 페이지를 새로운 페이지로 복사
|establish_pte // 페이지 테이블 포인터를 다시 설정
|set_pte
Page Fault ICA
|
-
do_page_fault [arch/i386/mm/fault.c]
-
handle_mm_fault [mm/memory.c]
-
handle_pte_fault
-
do_wp_page
-
alloc_page [include/linux/mm.h]
-
break_cow [mm/memory.c]
-
copy_cow_page
-
establish_pte
-
set_pte [include/asm/pgtable-3level.h]
간단히 말해서, 리눅스는 segmentation 과 pagnation 을 동시에 사용한다.
리눅스는 오직 4 개의 세그먼트 만을 사용한다:
__
4 GB--->| | |
| Kernel | | Kernel Space (Code + Data/Stack)
| | __|
3 GB--->|----------------| __
| | |
| | |
2 GB--->| | |
| Tasks | | User Space (Code + Data/Stack)
| | |
1 GB--->| | |
| | |
|________________| __|
0x00000000
Kernel/User Linear addresses
|
이전에도 말했듯이 리눅스는 Pagination 을 3 단계의 페이징을 이용해서 구현하지만, i386 환경에서는 실제로 그 중에서 2 단계 만을 사용한다:
------------------------------------------------------------------
L I N E A R A D D R E S S
------------------------------------------------------------------
\___/ \___/ \_____/
PD offset PF offset Frame offset
[10 bits] [10 bits] [12 bits]
| | |
| | ----------- |
| | | Value |----------|---------
| | | | |---------| /|\ | |
| | | | | | | | |
| | | | | | | Frame offset |
| | | | | | \|/ |
| | | | |---------|------ |
| | | | | | | |
| | | | | | | x 4096 |
| | | PF offset|_________|------- |
| | | /|\ | | |
PD offset |_________|----- | | | _________|
/|\ | | | | | | |
| | | | \|/ | | \|/
_____ | | | ------>|_________| PHYSICAL ADDRESS
| | \|/ | | x 4096 | |
| CR3 |-------->| | | |
|_____| | ....... | | ....... |
| | | |
Page Directory Page File
Linux i386 Paging
|
|
