커널 모듈은 Linux에만 해당됩니까, 아니면 일반적인 메커니즘입니까?

Andrew Tanenbaum이 제시한 아이디어는 일반적으로 Linux(또는 기존의 모놀리식 Unix 커널)에 직접 적용할 수 없습니다. 귀하의 질문에 대한 대답은 귀하가 제안한 것보다 훨씬 간단합니다. Linux 커널 모듈은 커널 이미지에 링크되지 않고 별도의 파일에 컴파일 및 링크된 커널 코드입니다. 이 별도의 커널 개체 파일(.ko)은 런타임 시 필요에 따라 커널 주소 공간에 로드될 수 있습니다. 커널 모듈로 컴파일할 수 있는 거의 모든 드라이버는 코드가 로드되면 기능적 차이 없이 커널 이미지에 정적으로 링크될 수도 있습니다.

모듈 코드는 다른 모든 커널 코드와 동일한 권한으로 실행되는 커널 코드입니다. 원칙적으로 커널 모듈은 모든 커널 코드를 대체할 수 있지만 이를 깔끔하게 수행하려면 커널 자체에서 모듈을 연결하는 메커니즘을 제공해야 합니다.

용어에 대한 참고 사항: 가드 링은 Multics 운영 체제에서 도입된 개념입니다. "링 0"부터 "링 3"까지는 인텔 프로세서에만 해당되는 용어입니다. 다른 프로세서 아키텍처에서는 사용자/관리 모드와 같은 다른 용어를 사용합니다. Intel 프로세서는 네 가지 권한 수준을 제공하지만 대부분의 운영 체제는 사용자 수준 코드용 링 3과 커널 코드용 링 0, 즉 다른 프로세서의 사용자/관리 모드를 미러링하는 두 가지 권한만 사용합니다. (3가지 권한 수준을 사용하는 OS/2는 예외입니다.)

최근 하드웨어 수준의 가상화 기술이 등장하면서 권한 수준의 개념이 확장되었습니다. 예를 들어 ARM 아키텍처는 사용자, 감독자, 하이퍼바이저라는 세 가지 권한 수준을 정의합니다. 농담으로 Intel 기반 시스템에서는 4개의 링이 사용되었습니다. 즉, 사용자 수준 코드용 링 3, (가상 머신) 커널 코드용 링 0, 하이퍼바이저 코드용 링 -1, SMM 모드용 링 -2입니다.

커널의 개념이 모든 운영 체제에 적용되는 것은 아닙니다. 이는 일반적이지만 특정 시스템에 정확히 어떻게 적용되는지는 논쟁의 여지가 있습니다.

프로그램이 서로 격리되어 있는 다중 프로그래밍 시스템에서 커널은 정확한 정의를 갖습니다. 즉, 커널은 모든 것에 액세스할 수 있는 시스템의 일부입니다. 커널은 고립된 부분이 아닙니다. 커널의 역할은 최소한 격리 메커니즘을 제공하는 것이지만 훨씬 더 많은 일을 할 수 있습니다. Linux를 포함한 전통적인 Unix 커널 아키텍처에서 커널에는 하드웨어 드라이버, 네트워크 프로토콜, 파일 시스템 드라이버 등도 포함되어 있습니다.

대부분의 시스템에서 실행 중인 프로그램 간의 격리는 하드웨어 기능(프로세서 권한 모드, 메모리 관리 장치)에 따라 달라집니다. 커널은 전체 시스템의 권한을 제어하는 ​​프로세서의 가장 높은 권한 모드에서 실행되는 시스템의 일부입니다. x86 프로세서에서는 이 모드를 "링 0"이라고 합니다. "링 0"은 일반적인 개념이 아니라 x86 용어입니다. 일반적인 개념은 "커널 모드" 또는 "권한 모드" 또는 "감독자 모드"라고 합니다.

"커널 모듈이 링 0에 대한 I/O 및 메모리 관리를 처리합니다"라는 설명은 의미가 없습니다. 커널은 전체적으로 메모리 관리(어떤 프로세스가 어떤 메모리를 소유하고 어떤 주소에 액세스할지 결정하는 수준)와 I/O(주변 장치 안팎으로 데이터를 복사하는 수준)를 처리합니다. 커널은 전체적으로 x86 프로세서의 링 0인 프로세서의 커널 모드에서 실행됩니다.

커널 모듈은 부팅 후 로드되는 커널의 일부입니다. 모듈과 시작 코드의 유일한 차이점은 로드되는 방식입니다. 커널 모듈의 코드는 부팅 시 로드된 커널 코드와 동일한 권한 수준을 가지며 동일한 기능을 수행할 수 있습니다(모듈로 로드할 수 있는 모든 코드는 부팅 시 이미지에도 포함될 수 있음). 커널 모듈은 Solaris, *BSD, Linux 등을 포함한 많은 최신 Unix 시스템에서 사용할 수 있습니다.