출처 : 리눅스 커널 프로그래밍 저 한동훈,원일용, 하홍준 / 한빛 미디어
모듈과 일체형 커널
운영체제의 커널을 어떻게 구성할 것인가에 대해서는 크게 두가지, 마이크로 커널과 일체형 (Monolithic)커널이 있습니다.
일체형 커널(Monolithic Kernel)은 전통적인 유닉스 설계 방식으로 스케줄러, 메모리 관리, 디스크 관리 같은 모든 기능이 하나의 큰 프로그램(커널)으로 구성됩니다. 이들 안에서는 각 자료구조를 자유롭게 공유할 수 있지만, 상호 의존성이 높아져서 일부의 잘못으로 전체 커널이 중지될 수 있습니다. 반면에, 하나의 프로그램이기 때문에 가장 효율적으로 동작할 수 있지만, 규모가 커질수록 개바로가 디버깅이 어려워진다는 단점이 있습니다.
마이크로 커널(Micro Kernl)은 중요한 부분만 핵심(Core)으로 남겨놓고, 프로세스 관리, 메모리 관리, 디스크 관리 같은 다양한 부분들을 서브시스템으로 나누며, 각 서브 시스템마다 프로세스가 할당되어 서비스를 제공하는 방식입니다. 이런 서브 시스템들은 사용자 영역에서 실행되면서 사용자 프로세스에게 서비스를 제공합니다. 이런 서브시스템들은 사용자 영역에서 실행되면서 사용자 프로세스에게 서비스를 제공합니다. 코어 부분은 커널 영역에서 실행되며, 하드웨어와 관리, 프로세스간의 메시지 전송같은 최소한의 서비스만 담당합니다. 이 방식에서는 각 서브시스템이 개별 프로세스로 수행되므로 서브시스템에 문제가 발생한 경우 해당 서브 시스템만 교체하면 되기 때문에 시스템 전체에 영향을 주지는 않습니다. 대신에,각 서브시스템간에 메시지 교환, 프로세스 전환(Context Switching)이 빈번하게 발생해서 효율성이 떨어진다고 알려져 있습니다. 마이크로 커널에서는 운여에제에서 가장 바쁜 스케줄러도 운영 중에 교체할 수 있다고 합니다. 물론 저는 아직까지 이런 운영체제를 볼기회가 없었습니다. 마이크로 커널의 예로는 GNU Hurd와 카네기 멜론 대학의 마크(Mach) 커널이 있습니다. 윈도우 NT는 마크 커널이지만, 서브 시스템의 일부가커널에 포함되어 있기 때문에 하이브리드 커널로 분류합니다.
리누스는 일체형 커널이 가장 효율적이라고 판단했기 때문에 리눅스도 일체형 커널로 되어 있습니다. 그러나 모듈을 도입함으러써 커널의 일부를 변경할 수 있게 되었습니다. 일체형 커널은 커널 전체가 하나의 프로그램이기 땨문에 초기 리눅스에서는 새로운 하드웨어를 추가하려면 커널을 다시 컴파일해야 햇습니다. 그러나 동적으로 커널 안에 코드를 삽입하고 제거할 수 있는 방법이 개발되었고, 오늘날의 커널 모듈이 되어 디바시스 드라이버로 널리 쓰이게 되었습니다. 모듈을 마이크로 커널과 혼동하는 경우가 종종 있습니다. 마이크로 커널은 서브 시스템을 교체할 수 있으며, 각 서브 시스템은 메시지 기반의 통신을 합니다. 모듈은 프로그램의 일부 코드를 동적으로 삽입하고, 교체할 수 있는 것이며, 커널은 여전히 하나의 프로그램입니다.
마이크로 커널과 일체형 커널 중에 어떤 것이 더 좋은지에 대해서는 정답이 없스빈다. 그래서 타넨바움과 리누스 사이에 치열한 논쟁이 오갔으며, 오이게 얼마나 재미가 있었던지 <<오픈소스>>라는 책에 그중 일부가 실리기까지 했습니다. 오픈소스라는 책 이름에 걸맞게 원서와 번역서 모두 인터넷에 무료로 공개되어 있습니다.
<<오픈소스>> 부록 A:타넨 바움 - 토발즈 논쟁
http://www.hanbitbook.co.kr/download/opensource/open_appendixA.pdf
모듈과 일체형 커널
운영체제의 커널을 어떻게 구성할 것인가에 대해서는 크게 두가지, 마이크로 커널과 일체형 (Monolithic)커널이 있습니다.
일체형 커널(Monolithic Kernel)은 전통적인 유닉스 설계 방식으로 스케줄러, 메모리 관리, 디스크 관리 같은 모든 기능이 하나의 큰 프로그램(커널)으로 구성됩니다. 이들 안에서는 각 자료구조를 자유롭게 공유할 수 있지만, 상호 의존성이 높아져서 일부의 잘못으로 전체 커널이 중지될 수 있습니다. 반면에, 하나의 프로그램이기 때문에 가장 효율적으로 동작할 수 있지만, 규모가 커질수록 개바로가 디버깅이 어려워진다는 단점이 있습니다.
마이크로 커널(Micro Kernl)은 중요한 부분만 핵심(Core)으로 남겨놓고, 프로세스 관리, 메모리 관리, 디스크 관리 같은 다양한 부분들을 서브시스템으로 나누며, 각 서브 시스템마다 프로세스가 할당되어 서비스를 제공하는 방식입니다. 이런 서브 시스템들은 사용자 영역에서 실행되면서 사용자 프로세스에게 서비스를 제공합니다. 이런 서브시스템들은 사용자 영역에서 실행되면서 사용자 프로세스에게 서비스를 제공합니다. 코어 부분은 커널 영역에서 실행되며, 하드웨어와 관리, 프로세스간의 메시지 전송같은 최소한의 서비스만 담당합니다. 이 방식에서는 각 서브시스템이 개별 프로세스로 수행되므로 서브시스템에 문제가 발생한 경우 해당 서브 시스템만 교체하면 되기 때문에 시스템 전체에 영향을 주지는 않습니다. 대신에,각 서브시스템간에 메시지 교환, 프로세스 전환(Context Switching)이 빈번하게 발생해서 효율성이 떨어진다고 알려져 있습니다. 마이크로 커널에서는 운여에제에서 가장 바쁜 스케줄러도 운영 중에 교체할 수 있다고 합니다. 물론 저는 아직까지 이런 운영체제를 볼기회가 없었습니다. 마이크로 커널의 예로는 GNU Hurd와 카네기 멜론 대학의 마크(Mach) 커널이 있습니다. 윈도우 NT는 마크 커널이지만, 서브 시스템의 일부가커널에 포함되어 있기 때문에 하이브리드 커널로 분류합니다.
리누스는 일체형 커널이 가장 효율적이라고 판단했기 때문에 리눅스도 일체형 커널로 되어 있습니다. 그러나 모듈을 도입함으러써 커널의 일부를 변경할 수 있게 되었습니다. 일체형 커널은 커널 전체가 하나의 프로그램이기 땨문에 초기 리눅스에서는 새로운 하드웨어를 추가하려면 커널을 다시 컴파일해야 햇습니다. 그러나 동적으로 커널 안에 코드를 삽입하고 제거할 수 있는 방법이 개발되었고, 오늘날의 커널 모듈이 되어 디바시스 드라이버로 널리 쓰이게 되었습니다. 모듈을 마이크로 커널과 혼동하는 경우가 종종 있습니다. 마이크로 커널은 서브 시스템을 교체할 수 있으며, 각 서브 시스템은 메시지 기반의 통신을 합니다. 모듈은 프로그램의 일부 코드를 동적으로 삽입하고, 교체할 수 있는 것이며, 커널은 여전히 하나의 프로그램입니다.
마이크로 커널과 일체형 커널 중에 어떤 것이 더 좋은지에 대해서는 정답이 없스빈다. 그래서 타넨바움과 리누스 사이에 치열한 논쟁이 오갔으며, 오이게 얼마나 재미가 있었던지 <<오픈소스>>라는 책에 그중 일부가 실리기까지 했습니다. 오픈소스라는 책 이름에 걸맞게 원서와 번역서 모두 인터넷에 무료로 공개되어 있습니다.
<<오픈소스>> 부록 A:타넨 바움 - 토발즈 논쟁
http://www.hanbitbook.co.kr/download/opensource/open_appendixA.pdf
'linux' 카테고리의 다른 글
vim 설정 (0) | 2010.06.30 |
---|---|
모듈의 상호참조 (0) | 2010.06.03 |
모듈에 대해 알아야 할것들 (0) | 2010.06.03 |
Hello 커널 모듈 작성 예제 (0) | 2010.06.02 |
모듈 개발. (0) | 2010.06.01 |
커널 소스 컴파일 (0) | 2010.06.01 |
/usr/lib/python2.4/site-packages/_sqlitecache.so: undefined symbol: g_assert_warning (0) | 2010.04.22 |
Git 1.6.1 설치 (0) | 2010.04.22 |
AttributeError: CHECKSUM_VALUE (0) | 2010.04.22 |
gtk 설치 중 오류 (0) | 2010.04.20 |