(1) 리눅스란?
: 흔히들 레드햇(RedHat) 리눅스, 데비앙(Debian) 리눅스 , 젠투(Gentoo) 리눅스라고 말하지만 엄밀한 의미에서 리눅스는 리눅스 커널만을 의미한다. 우리가 소위 말하는 레드햇이니 데비앙, 젠투 리눅스는 배포판을 의미하지, 리눅스 자체를 의미하지 않는다. 리눅스 커널은 리누스 토발즈를 위시한 세계 각지의 개발자에 의해 오늘도 활발하게 개발되고 있다. 이렇게 개발되는 이 커널을 리눅스라 말한다.

이러한 커널에는 말 그대로 커널만 있기 때문에 이것만 가지고는 아무것도 할 수 없다. 이 커널을 가지고 각 개발 업체들이 컴파일러(gcc, g++), 편집기(vi, emacs ), 웹브라우저(모질라 등)과 같은 응용 어플리케이션을 추가해서 만든 것이 리눅스 배포판이다. 배포판은 배포판을 만드는 업체에서 붙이는 이름에 따라 레드햇, 데비앙, 젠투 등으로 나뉘어진다. 배포판이 다르다고 해서 리눅스 커널이 달라지는 것은 아니다. 배포판이 다름으로 인해 포함되는 응용 어플리케이션의 종류는 다르지만 리눅스 커널은 버전이 다른다는 것과 벤더에 따라 약간의 수정이 가해졌다는 것 빼고는 동일하게 사용되고 있다.

이 리눅스 커널은 현재 2.6.16 버전까지 개발됐는데 해가 바뀔 때마다 개발 속도를 더해가고 있다. 이는 리눅스 커널개발에 많은 사람들이 참여하는 것이 가장 큰 이유겠지만 리누스 토발즈가 이전에 근무하던 트랜스메타를 떠나 오픈소스 개발연구소(OSDL)에서 리눅스 kernel 개발에 전념하는 것도 이유가 될 수 있을 것이다.


(2) 리눅스 커널의 이해
: 리눅스 커널 버전은 linux-2.4.18 혹은 linux-2.6.16과 같은 형식을 띄고 있다. 이는 전통적인 유닉스의 버전 표기법이 약간 변형된 형태이다. 제일 앞에 있는 숫자는 메이저 버전이라고 해서 커널의 구조나 기능에 급격한 변화가 있을 때마다 바뀌는 버전이다. 두번째 오는 숫자는 마이너 버전이라고 해 메이저급처럼 큰 변화는 아니지만 내부 구조면에서 많은 변화가 있을 때 바뀌는 버전이다.

마이너 버전이 2.6.x 와 같이 짝수인 경우에는 안정된 커널 소스임을 의미하며 2.5.x 와 같이 홀수인 경우에는 개발 버전을 의미한다. 마지막으로 오는 숫자는 패치 버전이라고 해 기능, 구조적 변화는 없지만 버그등으로 인해 소스가 약간 수정됐을 때마다 바뀌는 버전이다. 그리고 간혹 2.6.16.9 와 같이 패치버전 다음에 숫자 또는 문자가 올 수 있는데 이는 개발자 개인이 붙이는 비공식 버전을 의미한다.

현재 리눅스 커널 버넌은 2.6.16 인데 이 버전정보만으로 우리는 리눅스 커널이 크게 두번째 바뀌었고 두번 바뀐 것중에서 3번째 안정 버전이고(홀수는 개발 버전) 패치는 16번 가해졌다는 것을 알 수 있다.

리눅스 커널의 구조를 그림으로 나타내면 아래와 같다.



이 그림은 리눅스 커널의 구조를 잘 보여 준다. 사실 리눅스커널의 구조가 그림과 같이 명확하게 기능별로 나뉘어져 있지는 않다. 다른 OS들 특히 RTOS 에 비하면 리눅스 커널의 구조는 다소 경계가 모호한 편이다. 하지만 기능적으로는 이렇게 구분돼 있다고 보면 된다.


(3) System Call Interface
: 시스템 콜 인터페이스는 user mode 프로세스인 응용 애플리케이션이 커널의 기능을 사용 가능하게 해준다. 유닉스 시스템의 대표적인 특징 중에 하나는 user mode kernel mode가 나뉘어져 있다는 것이다. 리눅스 역시 처음 시작은 유닉스를 모델로 만들어졌기 때문에 user mode kernel mode 로 나뉘어져 있다.

Kernel mode는 특권 mode로서 모든 주소 공간에 접근할 수 있고 모든 명령(instruction)을 수행할 수 있다. 그러나 user mode 에서는 user mod에 할당된 주소 공간만 접근할 수 있고 kernel mode의 주소 공간에 대해서는 접근 불가능하다. 또한 시스템에 치명적인 영향을 끼칠 수 있는 특권 명령(lgdt, lidt, cli, sti )들은 사용할 수가 없다.

이렇게 user mode kernel mode를 나누어 놓은 이유는 응용 애플리케이션의 비정상적인 혹은 악의적인 수행에 대해서 시스템을 보호하기 위한 것이다.

응용 애플리케이션은 user mode에서 동작하기 때문에 커널 영역에 있는 커널 함수 또는 커널 자료 구조에 대해 접근할 수 없다. 응용 애플리케이션이 커널 영역에 있는 커널 함수 또는 자료 구조를 사용하기 위해서는 반드시 시스템 콜을 사용해야 한다.

시스템 콜은 소프트웨어 인터럽트를 사용해 구현된다. 응용 애플리케이션은 소프트웨어 인터럽트 명령어(ex: int 0x80, swi)를 명시적으로 호출해서 시스템 콜을 호출한다.


(4) Memory Management
: 메모리 자원은 시스템에 있어서 매우 귀중한 자원이다. 메모리를 얼마나 효율적으로 관리하느냐에 따라 시스템 성능이 결정된다. 메모리를 비효율적으로 관리한다면 메모리를 할당/해제하는데 많은 시간이 걸리고 단편화로 인해 남아 있는 공간을 제대로 활용하지 못하는 문제가 발생한다.

메모리 매니지먼트는 시스템에 있는 메모리 자원을 관리하는 부분으로서 리눅스는 메모리 관리 알고리듬으로 buddy system slab할당자를 사용한다.


(5) Task Management
: 태스크 매니지먼트는 태스크를 관리하는 부분이다. 태스트의 생성,소멸,중단 등을 담당한다. 태스크를 스케줄링하고 우선순위를 집행하고 등의 일이 모두 태스크 매니지먼트에서 이루어지는 일이다.


(6) IPC(Interprocess Communication)
: IPC는 프로세스간  통신을 담당하는 부분이다. 프로세스 모델에서는 페이징(paging)기법을 사용해 가상 주소를 사용하는데 각 프로세스에는 각기 다른 4GB(아키텍처마다 다름. i386, arm ) 크기의 가상 주소 공간을 가지게 된다. 이렇게 되면 프로세스 A 0x100번지와 프로세스 B 0x100번지는 가상 주소는 같지만 물리 주소는 완전히 다른 곳을 가르키게 된다.

페이징기법을 사용해 프로세스의 주소 공간을 분리함으로 생기는 장점으로는 다른 프로세스의 비정상적 혹은 악의적 수행으로부터 보호받을 수 있고 요구 페이징/swapping 기법을 사용해 적은 메모리를 가지고도 4GB 메모리가 있는 것처럼 사용할 수 있으며 애플리케이션을 컴파일할 때 수행 위치에 대해서 고민하지 않아도 된다는 등 많은 장점이 있다.

반면 단점으로는 가상 주소를 물리 주소로 변화하는데 오버헤드가 발생하고 프로세스간 통신에 있어서 쉽지 않다는 문제가 발생하게 된다.

IPC는 프로세스간  통신 기능을 제공해 주는 부분으로서 리눅스에서 IPC signal, message queue, shared memory, semaphore 등을 제공하고 있다.


(7) VFS(Virtual File System)
: 가상 파일 시스템은 각기 다른 파일 시스템과 디바이스 드라이브 등에 대해서 동일한 인터페이스를 제공하는 부분이다. 예를 들면 이렇다. ext2 파일 시스템에 있는 텍스트 파일에 데이터를 쓰던 vfat 파일 시스템에 있는 텍스트 파일에 파일을 쓰던 혹은 사운드 카드에 소리가 나게 데이터를 보내든 모두 write 시스템 콜을 사용한다.

이렇게 각기 다른 파일 시스템, 디바이스에 대해서 open, read, write, close 등과 같은 동일한 인터페이스 사용할 수 있게 해주는 부분이 바로 vfs이다.

리눅스가 이렇게 성장할 수 있게 된 이유중의 하나가 바로 이 VFS때문이다. VFS가 있음으로 인해 리눅스는 여러 파일 시스템을 사용할 수 있게 되었고 그럼으로 여러 운영체제와 함께 공존해서 사용하는데 장점이 있었다.


(8) BSD Socket Interface
: bind, connect, accept, send, recv 등으로 대변되는 BSD socket interface 를 제공하는 부분이다.


(9) File System
: ext2, ext3, vfat, jfs 등의 파일 시스템을 제공하는 부분이다.


(10) Network Protocol Stack
: ipv4, ipv6, atm, x25 와 같은 프로토콜 스택을 가지고 있는 부분이다.


(11) Device Driver
: 하드디스크, 키보드, 마우스, CD롬등 디바이스 드라이버를 포함하고 있는 부분이다. 예전에 리눅스는 디바이스 드라이브 지원이 미미해 사용하기 힘든 운영체제였다. 특히나 X-windows 시스템을 띄우기 위해서는 그래픽 카드 디바이스 드라이브가 있어야 하는데 대부분 사람들의 그래픽 카드를 리눅스에서 지원해 주지 못했었다. 때문에 X-windows 화면을 본 사람들을 축복받은 사람이라고 부르던 시절이 있었다. 현재는 물론 지난날 추억일 뿐이다.

'L inux > Kernel' 카테고리의 다른 글

시스템 콜(System Call) - 1  (0) 2011.09.26
리눅스 커널 컴파일  (0) 2011.09.26
리눅스 부팅과정  (0) 2011.09.23
리눅스 커널의 내부구조  (0) 2011.04.01
리눅스 커널  (3) 2011.04.01
by 민트앤라떼 2011. 9. 21. 13:19