[architecture] 리눅스가 왜 모 놀리 식 커널이라고 불리는가?

모 놀리 식 커널은 모든 서비스 (파일 시스템, VFS, 장치 드라이버 등)와 핵심 기능 (스케줄링, 메모리 할당 등)이 동일한 공간을 공유하는 긴밀한 그룹 인 커널입니다. 이것은 마이크로 커널과 직접적으로 반대된다 .

마이크로 커널은 핵심 기능이 시스템 서비스 및 장치 드라이버 (기본적으로 시스템 서비스 일뿐)와 분리되는 접근 방식을 선호합니다. 예를 들어 VFS (가상 파일 시스템)와 블록 장치 파일 시스템 (예 : minixfs)은 IPC를 사용하여 커널, 다른 서비스 및 사용자 프로세스와 통신하기 위해 커널 공간 외부에서 실행되는 별도의 프로세스입니다. 즉, Linux 의 모듈 인 경우 격리 된 프로세스를 나타내는 마이크로 커널 의 서비스 입니다.

모듈 식 커널 이라는 용어를 모 놀리 식 이외의 것으로 혼동하지 마십시오 . 일부 모 놀리 식 커널은 모듈 형 (예 : Linux)으로 컴파일 될 수 있습니다. 중요한 것은 모듈이 핵심 기능 (커널 공간)을 처리하는 동일한 공간에 삽입되고 실행되는 것입니다.

마이크로 커널의 장점은 실패한 서비스를 쉽게 다시 시작할 수 있다는 것입니다. 예를 들어 루트 파일 시스템이 중단되면 커널이 중지되지 않습니다. 그러나 이것은 매우 중요한 버그를 숨길 수 있기 때문에 단점으로 보일 수도 있습니다 (또는 문제가 지속적으로 해결되는 것처럼 보임). 배포 된 후에는 무언가를 편리하게 수정할 수없는 시나리오에서 큰 이점으로 여겨집니다.

마이크로 커널의 단점은 비동기 IPC 메시징이 특히 fibrils 가 구현 된 경우 디버깅하기가 매우 어려워 질 수 있다는 것 입니다. 또한 FS / 쓰기 문제를 추적한다는 것은 사용자 공간 프로세스, 블록 장치 서비스, VFS 서비스, 파일 시스템 서비스 및 PCI 서비스 (아마도)를 검사하는 것을 의미합니다. 당신이 그것에 빈 내용이 있으면, IPC 서비스를 볼 때입니다. 이것은 모 놀리 식 커널에서 종종 더 쉽습니다. GNU Hurd 는 이러한 디버깅 문제 ( reference )로 어려움을 겪고 있습니다 . 복잡한 메시지 대기열을 처리 할 때 검사 점에 들어 가지 않을 것입니다. 마이크로 커널은 희미한 마음을위한 것이 아닙니다.

작동하고 안정적인 커널의 최단 경로는 모 놀리 식 접근법입니다. 두 가지 방법 모두 POSIX 인터페이스를 제공 할 수 있습니다. 여기서 커널 디자인은 특정 디자인에서 실행할 코드를 작성하려는 사람에게는 거의 관심이되지 않습니다.

프로덕션에서는 Linux (단일)를 사용합니다. 그러나 커널 개발에 대한 대부분의 학습, 해킹 또는 땜질은 마이크로 커널, 특히 HelenOS에 들어갑니다 .

편집하다

매우 긴 대답을 통해 이것을 얻었을 경우 아마도 ‘ 커널 디자인에 관한 위대한 Torvalds-Tanenbaum 토론 ‘을 읽는 것이 재미있을 것입니다 . 2013 년에 책을 읽은 후 20 년이 넘는 책을 읽는 것이 더 재미있었습니다. 가장 재미있는 부분은 마지막 메시지 중 하나에서 Linus의 서명이었습니다.

Linus "my first, and hopefully last flamefest" Torvalds

분명히 x86이 곧 폐기 될 것이라는 Tanenbaum의 예측보다 더 이상 실현되지 않았습니다.

NB :

“Minix”라고 말하면 Minix 3을 암시하지 않습니다. 또한 HURD를 언급 할 때 (대부분) Mach 마이크로 커널을 언급하고 있습니다. 다른 사람들의 최근 연구를 버리려는 의도는 아닙니다.

---

답변