커널(운영체제)

Kernel (operating system)
커널이 응용 프로그램 소프트웨어를 컴퓨터의 하드웨어에 연결하는 방법을 지나치게 단순화합니다.

커널은 컴퓨터 운영체제의 핵심에 있는 컴퓨터 프로그램으로 일반적으로 [1]시스템의 모든 것을 완벽하게 제어합니다.운영 체제 코드 중 항상 메모리에[2] 상주하며 하드웨어와 소프트웨어 구성 요소 간의 상호 작용을 용이하게 하는 부분입니다.전체 커널은 장치 드라이버를 통해 모든 하드웨어 리소스(예: I/O, 메모리, 암호화)를 제어하고, 이러한 리소스와 관련된 프로세스 간의 충돌을 조정하며, CPU 및 캐시 사용량, 파일 시스템, 네트워크 소켓 등과 같은 공통 리소스의 활용을 최적화합니다.대부분의 시스템에서 커널은 부팅 (부트로더 다음) 처음 로드되는 프로그램 중 하나입니다.소프트웨어의 메모리, 주변기기, 입출력(I/O) 요청뿐만 아니라 나머지 시동 요청도 처리하여 중앙 처리 장치의 데이터 처리 명령으로 변환합니다.

커널의 중요 코드는 보통 별도의 메모리 영역에 로드되는데, 이 영역은 애플리케이션 소프트웨어나 운영 체제의 덜 중요한 다른 부분에 의해 액세스되지 않도록 보호됩니다.커널은 이 보호된 커널 공간에서 프로세스 실행, 하드 디스크와 같은 하드웨어 장치 관리, 인터럽트 처리 등과 같은 작업을 수행합니다.이와는 대조적으로 브라우저, 워드 프로세서 또는 오디오 또는 비디오 플레이어와 같은 응용 프로그램은 별도의 메모리 영역, 즉 사용자 공간을 사용합니다.이러한 분리로 인해 사용자 데이터와 커널 데이터가 서로 간섭하여 불안정 및 [1]느려지는 것을 방지할 수 있으며, 애플리케이션이 오작동하여 다른 애플리케이션에 영향을 미치거나 전체 운영 체제가 손상되는 것을 방지할 수 있습니다.커널이 애플리케이션 주소 공간에 포함된 시스템에서도 승인되지 않은 애플리케이션이 커널을 수정하지 못하도록 메모리 보호 기능이 사용됩니다.

커널의 인터페이스낮은 수준의 추상화 계층입니다.프로세스가 커널에서 서비스를 요청할 때는 보통 래퍼 기능을 통해 시스템 호출을 실행해야 합니다.

다양한 커널 아키텍처 설계가 있습니다.단일 커널은 주로 속도를 위해 CPU가 슈퍼바이저 모드에서 실행되는 단일 주소 공간에서 전적으로 실행됩니다.마이크로커넬은 사용자 프로세스처럼 사용자 [3]공간에서 대부분의 서비스를 실행하지만 모든 서비스를 실행하는 것은 아닙니다. 주로 복원력[4]모듈화를 위해 사용자 프로세스가 실행하는 것입니다.MINIX 3은 마이크로커널 설계의 주목할 만한 예입니다.대신, 리눅스 커널은 모듈식이기는 하지만, 런타임에 로드 가능한 커널 모듈을 삽입하고 제거할 수 있기 때문에 단일 커널입니다.

컴퓨터 시스템의 이 중심 구성 요소는 프로그램을 실행하는 역할을 합니다.커널은 실행 중인 많은 프로그램 중 어떤 프로그램을 프로세서 또는 프로세서에 할당해야 하는지 결정하는 책임을 가집니다.

랜덤 액세스 메모리

RAM(Random-access memory)은 프로그램 명령과 [a]데이터를 모두 저장하는 데 사용됩니다.일반적으로, 프로그램이 실행되기 위해서는 둘 다 메모리에 존재해야 합니다.여러 프로그램이 메모리에 액세스하기를 원하기 때문에 컴퓨터가 사용할 수 있는 메모리보다 더 많은 메모리를 요구하는 경우가 많습니다.커널은 각 프로세스가 사용할 수 있는 메모리를 결정하고 메모리가 충분하지 않을 때 수행할 작업을 결정하는 역할을 합니다.

입출력장치

I/O 장치에는 키보드, 마우스, 디스크 드라이브, 프린터, USB 장치, 네트워크 어댑터 및 디스플레이 장치와 같은 주변 장치가 포함됩니다.커널은 애플리케이션이 구현 세부사항을 알 필요가 없도록 커널에 의해 추상화되는 이러한 장치를 사용할 수 있는 편리한 방법을 제공합니다.

자원관리

리소스 관리에 필요한 핵심 측면은 실행 도메인(주소 공간)과 도메인 [5]내 리소스에 대한 액세스를 중재하는 데 사용되는 보호 메커니즘을 정의하는 것입니다.커널은 또한 동기화프로세스간 통신(IPC)을 위한 방법을 제공합니다.이러한 구현은 커널 자체 내에 위치할 수도 있고 커널이 실행 중인 다른 프로세스에 의존할 수도 있습니다.커널은 서로가 제공하는 설비에 대한 액세스를 제공하기 위해 IPC를 제공해야 하지만 커널은 실행 중인 프로그램에 이러한 설비에 대한 액세스 요청을 할 수 있는 방법을 제공해야 합니다.커널은 프로세스 또는 스레드 간의 컨텍스트 전환도 담당합니다.

메모리관리

커널은 시스템의 메모리에 대한 완전한 액세스 권한을 가지며 프로세스가 필요에 따라 이 메모리에 안전하게 액세스할 수 있도록 해야 합니다.대개 이 작업의 첫 단계는 가상 주소 지정이며, 일반적으로 페이징 및/또는 세그먼트화를 통해 달성됩니다.가상 주소 지정을 통해 커널은 주어진 물리적 주소가 다른 주소, 즉 가상 주소인 것처럼 보이게 합니다.가상 주소 공간은 프로세스마다 다를 수 있습니다. 한 프로세스가 특정 (가상) 주소에서 액세스하는 메모리는 다른 프로세스가 동일한 주소에서 액세스하는 메모리와 다를 수 있습니다.이를 통해 모든 프로그램이 (커널과는 별도로) 실행 중인 유일한 프로그램인 것처럼 동작할 수 있으므로 응용 프로그램이 [6]서로 충돌하는 것을 방지할 수 있습니다.

많은 시스템에서 프로그램의 가상 주소는 현재 메모리에 없는 데이터를 의미할 수 있습니다.가상 어드레싱에 의해 제공되는 간접 계층은 운영 체제가 하드 드라이브와 같은 다른 데이터 저장소를 사용하여 그렇지 않으면 메인 메모리(RAM)에 남아 있어야 할 것들을 저장할 수 있게 해줍니다. 결과적으로 운영 체제는 시스템이 물리적으로 사용 가능한 것보다 더 많은 메모리를 프로그램이 사용하도록 허용할 수 있습니다.프로그램이 현재 RAM에 없는 데이터를 필요로 할 때 CPU는 커널에 이러한 현상이 발생했음을 알리고 커널은 비활성 메모리 블록의 내용을 디스크에 기록(필요한 경우)하고 프로그램이 요청한 데이터로 대체하여 응답합니다.그러면 프로그램이 중지된 지점부터 프로그램을 다시 시작할 수 있습니다.이 방식은 일반적으로 수요 페이징(demand paging)이라고 합니다.

가상 주소 지정을 통해 서로 연결된 두 영역에 메모리의 가상 파티션을 생성할 수도 있습니다. 하나는 커널 공간(커널 공간)을 위해 예약되고 다른 하나는 애플리케이션(사용자 공간)을 위해 예약됩니다.프로세서는 응용 프로그램이 커널 메모리를 어드레싱할 수 없으므로 응용 프로그램이 실행 중인 커널을 손상시키는 것을 방지합니다.메모리 공간의 이러한 기본적인 분할은 실제 범용 커널의 현재 설계에 많은 기여를 했으며, 일부 연구 커널(: 특이점)이 다른 접근 방식을 취하지만 이러한 시스템에서 거의 보편적입니다.

기기관리

유용한 기능을 수행하기 위해 프로세스는 장치 드라이버를 통해 커널에 의해 제어되는 컴퓨터에 연결된 주변 장치에 대한 액세스가 필요합니다.디바이스 드라이버(device driver)는 OS를 대신하여 하드웨어/소프트웨어 인터페이스(HSI)를 통해 하드웨어 디바이스를 캡슐화, 모니터링 및 제어하는 컴퓨터 프로그램입니다.특정 하드웨어를 제어하고 통신하는 방법에 대한 API, 절차 및 정보를 운영 체제에 제공합니다.장치 드라이버는 모든 OS와 애플리케이션에 중요하고 필수적인 종속 요소입니다.드라이버의 설계 목표는 추상화입니다. 드라이버의 기능은 OS가 요구하는 추상 함수 호출(프로그래밍 호출)을 장치별 호출로 변환하는 것입니다.이론적으로 장치는 적합한 드라이버와 올바르게 작동해야 합니다.장치 드라이버는 비디오 카드, 사운드 카드, 프린터, 스캐너, 모뎀, 네트워크 카드 등에 사용됩니다.

하드웨어 수준에서 디바이스 드라이버의 일반적인 추상화는 다음과 같습니다.

  • 직접 인터페이싱
  • 고급 인터페이스(비디오 BIOS) 사용
  • 하위 수준 장치 드라이버 사용(디스크 드라이버 사용 파일 드라이버)
  • 전혀 다른 작업을 수행하면서 하드웨어로 작업 시뮬레이션

그리고 소프트웨어 수준에서 디바이스 드라이버 추상화는 다음과 같습니다.

  • 운영 체제가 하드웨어 리소스에 직접 액세스할 수 있도록 허용
  • 프리미티브 구현만 가능
  • TWAIN과 같은 비드라이버 소프트웨어를 위한 인터페이스 구현
  • 언어 구현(흔히 PostScript와 같은 고급 언어)

예를 들어, 화면에서 사용자에게 무엇인가를 보여주기 위해, 애플리케이션은 커널에 요청을 하고, 커널은 요청을 디스플레이 드라이버에 전달하고, 이 드라이버는 실제로 문자/[6]픽셀을 플롯할 책임이 있습니다.

커널은 사용 가능한 디바이스 목록을 유지해야 합니다.이 목록은 사전에 알 수 있으며(예: 사용 가능한 하드웨어가 변경될 경우 커널이 다시 작성될 임베디드 시스템에서), 사용자가 구성하거나(일반적으로 개인용으로 설계되지 않은 시스템에서), 런타임에 운영 체제가 감지할 수 있습니다(일반적으로 플러그플레이라고 함).플러그 앤 플레이 시스템에서 장치 관리자는 먼저 PCI(Peripheral Component Interconnect) 또는 USB(Universal Serial Bus)와 같은 다양한 주변 버스에 대한 검색을 수행하여 설치된 장치를 탐지한 다음 적절한 드라이버를 검색합니다.

장치 관리는 매우 OS 고유의 주제이기 때문에 이러한 드라이버는 커널 설계의 종류에 따라 다르게 처리되지만, 모든 경우에 커널은 드라이버가 어떤 포트나 메모리 위치를 통해 장치에 물리적으로 액세스할 수 있도록 I/O를 제공해야 합니다.장치 관리 시스템을 설계할 때 중요한 결정을 내려야 합니다. 일부 설계 액세스에는 컨텍스트 스위치가 포함되어 작업이 CPU 집약적이고 상당한 성능 [citation needed]오버헤드를 쉽게 유발할 수 있기 때문입니다.

시스템 호출

컴퓨팅에서 시스템 호출(system call)은 프로세스가 일반적으로 실행 권한이 없는 운영 체제의 커널에서 서비스를 요청하는 방식입니다.시스템 호출은 프로세스와 운영 체제 사이의 인터페이스를 제공합니다.시스템과 상호 작용하는 대부분의 작업은 사용자 수준의 프로세스에 사용할 수 없는 권한이 필요합니다. 예를 들어 시스템에 있는 장치로 I/O를 수행하거나 다른 프로세스와의 모든 형태의 통신은 시스템 호출을 사용해야 합니다.

시스템 호출은 응용 프로그램이 운영 체제에 서비스를 요청할 때 사용하는 메커니즘입니다.그들은 프로세서가 모드를 바꾸도록 하는 기계 코드 명령을 사용합니다.슈퍼바이저 모드에서 보호 모드로의 예를 들 수 있습니다.여기서 운영체제는 하드웨어 장치나 메모리 관리 장치에 액세스하는 등의 작업을 수행합니다.일반적으로 운영 체제는 운영 체제와 일반 사용자 프로그램 사이에 위치하는 라이브러리를 제공합니다.보통 Glibc나 윈도우 API와 같은 C 라이브러리입니다.라이브러리는 커널에 정보를 전달하고 슈퍼바이저 모드로 전환하는 낮은 수준의 세부 정보를 처리합니다.시스템 호출에는 닫기, 열기, 읽기, 대기 및 쓰기가 포함됩니다.

유용한 작업을 실제로 수행하기 위해서는 커널이 제공하는 서비스에 접근할 수 있어야 합니다.이것은 각 커널마다 다르게 구현되지만 대부분은 C 라이브러리나 API제공하여 관련 커널 [7]기능을 호출합니다.

커널 함수를 호출하는 방법은 커널마다 다릅니다.메모리 분리가 사용 중인 경우 사용자 프로세스가 커널을 직접 호출하는 것은 불가능합니다. 이는 프로세서의 액세스 제어 규칙을 위반하는 것이기 때문입니다.몇 가지 가능성이 있습니다.

  • 소프트웨어 시뮬레이션 인터럽트를 사용합니다.이 방법은 대부분의 하드웨어에서 사용할 수 있으므로 매우 일반적입니다.
  • 콜게이트를 이용합니다.콜 게이트는 프로세서에 알려진 위치에 있는 커널 메모리의 목록에 커널이 저장하는 특수 주소입니다.프로세서가 해당 주소로 호출을 감지하면 액세스 위반을 일으키지 않고 대상 위치로 리디렉션됩니다.이를 위해서는 하드웨어 지원이 필요하지만 이를 위한 하드웨어는 매우 일반적입니다.
  • 특별한 시스템 호출 지침을 사용합니다.이 기술을 사용하려면 특별한 하드웨어 지원이 필요한데, 일반 아키텍처(특히 x86)에는 이러한 하드웨어 지원이 부족할 수 있습니다.그러나 시스템 호출 명령은 x86 프로세서의 최근 모델에 추가되었으며 일부 PC용 운영 체제에서는 사용 가능한 경우 이 명령을 사용합니다.
  • 메모리 기반 대기열 사용.많은 수의 요청을 하지만 각 요청의 결과를 기다릴 필요가 없는 애플리케이션은 커널이 요청을 찾기 위해 주기적으로 검색하는 메모리 영역에 요청의 세부 정보를 추가할 수 있습니다.

커널 설계 결정

보호.

커널 설계에서 중요한 고려 사항은 결함(내결함성) 및 악의적인 행동(보안)으로부터 보호하기 위한 지원입니다.이러한 두 가지 측면은 일반적으로 명확하게 구분되지 않으며, 커널 설계에서 이러한 구분을 채택하면 [5]보호를 위한 계층 구조가 거부됩니다.

커널이 제공하는 메커니즘 또는 정책은 다음과 같은 몇 가지 기준에 따라 분류될 수 있습니다: 정적(컴파일 타임에 강제됨) 또는 동적(런 타임에 강제됨); 사전 또는 사후 탐지; 이들이 만족하는 보호 원칙에 따라(예:데닝[8][9]); 하드웨어 지원인지 언어 기반인지; 개방형 메커니즘인지, 구속력 있는 정책인지 등입니다.

계층적 보호[10] 도메인 지원은 일반적으로 CPU 모드를 사용하여 구현됩니다.

많은 커널들은 커널에 의해 관리되는 기본 객체에 대한 제한된 접근을 허용하는 사용자 코드에 제공되는 객체인 "기능"의 구현을 제공합니다.일반적인 예로는 파일 처리가 있습니다. 파일은 영구 저장 장치에 저장된 정보를 표현한 것입니다.커널은 읽기, 쓰기, 삭제 또는 실행을 포함한 다양한 작업을 수행할 수 있지만 사용자 수준의 애플리케이션은 이러한 작업 중 일부만 수행하도록 허용될 수 있습니다(예: 파일 읽기만 허용될 수 있음).이것의 일반적인 구현은 커널이 애플리케이션(일반적으로 "파일 핸들"이라고 함)에 개체를 제공하는 것이며, 애플리케이션은 이 개체에 대해 작업을 호출할 수 있으며, 커널은 작업 요청 시에 작업을 확인합니다.이러한 시스템은 커널이 관리하는 모든 객체, 그리고 실제로 다른 사용자 애플리케이션에 의해 제공되는 객체를 포함하도록 확장될 수 있습니다.

기능의 하드웨어 지원을 제공하는 효율적이고 간단한 방법은 모든 메모리 액세스에 대한 액세스 권한 확인을 메모리 관리 장치(MMU)에 위임하는 것이며, 이는 기능 기반 [11]주소 지정이라고 불리는 메커니즘입니다.대부분의 상용 컴퓨터 아키텍처는 이러한 MMU 지원 기능이 부족합니다.

대안적 접근법은 일반적으로 지원되는 계층 도메인을 사용하여 기능을 시뮬레이션하는 것입니다.이 방법에서 각 보호 개체는 응용 프로그램이 액세스할 수 없는 주소 공간에 상주해야 하며 커널은 이러한 메모리에 기능 목록을 유지합니다.애플리케이션이 기능에 의해 보호되는 개체에 액세스해야 할 경우 시스템 호출을 수행하고 커널은 애플리케이션의 기능이 요청된 작업을 수행할 수 있는 권한을 부여하는지 여부와 요청이 허용되는지 여부(직접 또는 다른 사용자 수준 프로세스에 요청을 위임하여)를 확인합니다.주소 공간 전환의 성능 비용은 객체 간의 복잡한 상호 작용을 갖는 시스템에서는 이 접근법의 실용성을 제한하지만, 접근이 자주 되지 않거나 성능이 [12][13]신속하지 않을 것으로 예상되는 객체에 대해서는 현재 운영 체제에서 사용됩니다.

펌웨어가 보호 메커니즘을 지원하지 않는 경우 페이지 테이블을 조작하여 기능을 시뮬레이션하는 등 상위 수준의 보호 시뮬레이션이 가능하지만 성능에 영향을 미칠 [14]수 있습니다.그러나 언어 기반 [15]보호를 사용하는 시스템에서는 하드웨어 지원 부족이 문제가 되지 않을 수 있습니다.

중요한 커널 설계 결정은 보안 메커니즘과 정책이 구현되어야 할 추상화 수준을 선택하는 것입니다.커널 보안 메커니즘은 상위 [11][16][17][18][19]수준의 보안을 지원하는 데 중요한 역할을 합니다.

한 가지 접근 방식은 펌웨어 및 커널 지원을 사용하여(위 참조) 악성 동작에 대한 보안 정책을 구축하고(필요한 경우 암호화 메커니즘과 같은 기능을 추가) 컴파일러에 일부 책임을 위임하는 것입니다.컴파일러 및/또는 응용 프로그램 수준에 보안 정책 적용을 위임하는 접근 방식을 종종 언어 기반 보안이라고 합니다.

현재 주류 운영 체제에는 많은 중요한 보안 메커니즘이 없기 때문에 응용 프로그램 추상화 [16]수준에서 적절한 보안 정책을 구현하는 데 방해가 됩니다.사실 컴퓨터 보안에서 흔히 볼 수 있는 오해는 커널 [16]지원과 관계없이 모든 보안 정책을 응용 프로그램에서 구현할 수 있다는 것입니다.

Mars Research Group 개발자들에 따르면 고립성의 결여는 [20]커널 보안을 약화시키는 주요 요인 중 하나라고 합니다.그들은 주로 리눅스 [21][22]커널에서 보호를 위한 드라이버 격리 프레임워크를 제안합니다.

하드웨어 또는 언어 기반 보호

오늘날 일반적인 컴퓨터 시스템은 어떤 프로그램이 어떤 데이터에 액세스할 수 있는지에 대해 하드웨어로 강제된 규칙을 사용합니다.프로세서는 실행을 모니터링하고 커널 메모리에 기록을 시도하는 사용자 프로세스와 같이 규칙을 위반하는 프로그램을 중지합니다.기능 지원이 부족한 시스템에서는 별도의 주소 [23]공간을 사용하여 프로세스를 서로 분리합니다.사용자 프로세스에서 커널로의 호출은 전술한 시스템 호출 방법 중 하나를 사용하도록 요구함으로써 조정됩니다.

언어 기반 보호를 사용하는 것도 대안입니다.언어 기반 보호 시스템에서 커널은 신뢰할 수 있는 언어 컴파일러에 의해 생성된 코드만 실행하도록 허용합니다.그런 다음 프로그래머가 [15]보안 요구 사항을 위반하는 작업을 하도록 명령할 수 없도록 언어가 설계될 수 있습니다.

이 접근 방식의 장점은 다음과 같습니다.

  • 별도의 주소 공간이 필요 없습니다.주소 공간 간의 전환은 매우 많은 오버헤드를 야기하는 느린 동작이며, 현재 운영 체제에서 불필요한 전환을 방지하기 위해 많은 최적화 작업이 수행되고 있습니다.언어 기반 보호 시스템에서는 모든 코드가 동일한 주소 공간에서 안전하게 작동할 수 있기 때문에 전환이 전혀 필요하지 않습니다.
  • 유연성.프로그래밍 언어를 통해 표현되도록 설계될 수 있는 모든 보호 체계는 이 방법을 사용하여 구현될 수 있습니다.보호 체계(예: 계층적 시스템에서 능력 기반 시스템으로)를 변경할 경우 새 하드웨어가 필요하지 않습니다.

단점은 다음과 같습니다.

  • 애플리케이션 시작 시간이 길어집니다.응용 프로그램을 시작할 때 반드시 확인해야 합니다. 응용 프로그램이 올바른 컴파일러에 의해 컴파일되었는지 확인하거나 소스 코드 또는 바이트 코드에서 다시 컴파일해야 할 수도 있습니다.
  • 융통성 없는 유형의 시스템.기존 시스템에서는 애플리케이션이 안전하지 않은 작업을 수행하는 경우가 많습니다.이러한 작업은 언어 기반 보호 시스템에서는 허용될 수 없습니다. 즉, 응용프로그램을 다시 작성해야 할 수도 있고 경우에 따라 성능이 저하될 수도 있습니다.

언어 기반 보호 기능이 있는 시스템의 예로는 JX마이크로소프트Singularity 등이 있습니다.

공정협조

Edsger Dijkstra는 논리적 관점에서 이진 세마포어에서 작동하는 원자 잠금 및 잠금 해제 작업이 프로세스 협력의 [24]어떤 기능을 표현하기에 충분한 기본 요소임을 증명했습니다.그러나 이 접근 방식은 일반적으로 안전성과 효율성 측면에서 부족한 것으로 간주되는 반면 메시지 전달 접근 방식은 [25]더 유연합니다.여러 가지 다른 접근 방식(하위 또는 상위 수준)도 사용할 수 있으며, 많은 최신 커널이 공유 메모리 및 원격 프로시저 호출과 같은 시스템을 지원합니다.

입출력장치관리

I/O 장치가 병렬 공동 운영 프로세스로서 다른 프로세스와 균일하게 처리되는 커널 개념은 Brinch Hansen에 의해 처음 제안되고 구현되었습니다(비록 유사한 아이디어가 1967년에[26][27] 제안되었지만).이에 대한 Hansen의 설명에서 "공통" 프로세스는 내부 프로세스라고 하고 I/O 장치는 외부 [25]프로세스라고 합니다.

물리적 메모리와 유사하게 응용프로그램이 컨트롤러 포트와 레지스터에 직접 액세스할 수 있도록 허용하면 컨트롤러가 오작동하거나 시스템이 다운될 수 있습니다.이를 통해 장치의 복잡성에 따라 일부 장치는 프로그래밍하기가 놀라울 정도로 복잡해지고 여러 개의 컨트롤러를 사용할 수 있습니다.따라서 장치를 관리하기 위해 보다 추상적인 인터페이스를 제공하는 것이 중요합니다.이 인터페이스는 일반적으로 디바이스 드라이버 또는 하드웨어 추상화 계층에 의해 수행됩니다.애플리케이션에서 이러한 장치에 액세스해야 하는 경우가 많습니다.커널은 어떤 방식으로든 시스템을 쿼리함으로써 이러한 장치의 목록을 유지해야 합니다.이 작업은 BIOS 또는 다양한 시스템 버스(예: PCI/PCI 또는 USB) 중 하나를 통해 수행할 수 있습니다.비디오 드라이버의 예를 들어, 애플리케이션이 디바이스에 대한 동작(예를 들어, 문자 표시)을 요청할 때, 커널은 이 요청을 현재 활성 비디오 드라이버로 전송할 필요가 있습니다.비디오 드라이버는 이 요청을 수행해야 합니다.프로세스통신(IPC)의 한 예입니다.

커널 차원의 설계 접근방식

위에 나열된 작업 및 기능은 설계 및 구현에서 서로 다른 여러 가지 방법으로 제공될 수 있습니다.

메커니즘과 정책의 분리 원칙은 미시적 [28][29]커널과 단일 커널의 철학의 실질적인 차이입니다.여기서 메커니즘은 다양한 정책을 구현할 수 있도록 지원하는 반면, 정책은 특정한 "운영 모드"입니다.예:

  • 메커니즘:사용자 로그인 시도가 인증 서버로 라우팅됨
  • 정책: 인증 서버에 데이터베이스에 저장된 암호에 대해 검증된 암호가 필요합니다.

메커니즘과 정책이 분리되어 있기 때문에 보안 토큰을 사용해야 하는 등 정책을 쉽게 변경할 수 있습니다.

최소한의 마이크로커널에서는 아주 기본적인 몇 가지 정책이 [29]포함되어 있으며, 그 메커니즘을 통해 커널 위에서 실행 중인 것(운영 체제와 다른 응용 프로그램의 나머지 부분)이 어떤 정책(메모리 관리, 고급 프로세스 스케줄링, 파일 시스템 관리 등)[5][25]을 채택할지 결정할 수 있습니다.단일 커널은 대신 많은 정책을 포함하는 경향이 있으므로 시스템의 나머지 부분이 정책에 의존하도록 제한합니다.

Per Brinch Hansen은 메커니즘과 [5][25]정책의 분리에 찬성하는 주장을 제시했습니다.이러한 구분을 제대로 이행하지 못한 것은 컴퓨터 [30][31][32]아키텍처에서 흔히 볼 수 있는 문제인 기존 운영 [5]체제의 실질적인 혁신 부족의 주요 원인 중 하나입니다.모놀리식 설계는 보호에 대한 "커널 모드"/"사용자 모드" 아키텍처 접근법(기술적으로 계층적 보호 도메인이라고 함)에 의해 유도되며, 이는 종래의 상용 [33]시스템에서 일반적입니다; 사실,[33] 보호가 필요한 모든 모듈은 커널에 포함되는 것이 좋습니다.단일 설계와 "특권 모드" 사이의 이러한 연결은 메커니즘-정책 [5]분리라는 핵심 이슈로 재구성될 수 있습니다. 실제로 "특권 모드" 아키텍처 접근 방식은 보호 메커니즘과 보안 정책을 결합하는 반면, 주요 대안 아키텍처 접근 방식인 기능 기반 어드레싱은 명확하게 구분됩니다.s 둘 사이에 마이크로커널[5] 설계를 자연스럽게 유도합니다(보호와 보안의 분리 참조).

모놀리식 커널은 동일한 주소 공간(커널 공간)에서 모든 코드를 실행하는 반면 마이크로커널은 코드베이스의 [4]유지보수성과 모듈성을 향상시키는 것을 목표로 사용자 공간에서 대부분의 서비스를 실행하려고 합니다.대부분의 커널은 이러한 범주 중 하나에 정확히 들어맞지 않고 오히려 이 두 설계 사이에서 발견됩니다.이런 것들을 하이브리드 커널이라고 합니다.나노커넬엑소커넬과 같은 더 이국적인 디자인은 이용할 수 있지만 생산 시스템에는 거의 사용되지 않습니다.를 들어 Xen 하이퍼바이저는 엑소커널입니다.

모놀리식 알맹이

모놀리식 커널의 다이어그램

단일 커널에서 모든 OS 서비스는 메인 커널 스레드와 함께 실행되므로 동일한 메모리 영역에 상주합니다.이 방법은 풍부하고 강력한 하드웨어 액세스를 제공합니다.유닉스 개발자 켄 톰슨(Ken Thompson)은 "모놀리식 [34]커널을 구현하는 것이 그의 의견에 더 쉽다"고 말했습니다.모놀리식 커널의 주요 단점은 시스템 구성 요소 간의 의존성입니다. 장치 드라이버의 버그로 인해 전체 시스템이 다운될 수 있습니다. 그리고 큰 커널은 유지보수가 매우 어려워질 수 있습니다.톰슨은 또한 "[[34]모노리식 커널]이 수정됨에 따라 서둘러 엉망으로 변하는 것도 더 쉽다"고 말했습니다.

전통적으로 유닉스 계열 운영 체제에서 사용되는 단일 커널에는 운영 체제 핵심 기능과 장치 드라이버가 모두 포함되어 있습니다.단일 커널은 모든 커널 관련 작업을 수행하는 데 필요한 모든 코드를 포함하는 단일 프로그램입니다.라이브러리에 넣을 수 없는 대부분의 프로그램이 접근해야 하는 모든 부분은 커널 공간에 있습니다.장치 드라이버, 스케줄러, 메모리 처리, 파일 시스템 및 네트워크 스택.많은 시스템 호출이 애플리케이션에 제공되어 애플리케이션이 모든 서비스에 액세스할 수 있습니다.처음에는 필요하지 않을 수도 있는 서브시스템으로 구성된 단일 커널은 일반적인 의미에서는 더 적합하지만 하드웨어용으로 특별히 설계된 것과 비슷하거나 더 빠른 지점으로 조정할 수 있습니다.

리눅스 커널, FreeB와 같은 현대의 단일 커널SD 커널, AIX 커널, HP-UX 커널, 솔라리스 커널 모두 유닉스 계열 운영체제 범주에 속하며, 로드 가능한 커널 모듈을 지원하며, 모듈을 런타임에 커널에 로드할 수 있으며, 필요에 따라 커널의 기능을 쉽게 확장할 수 있습니다.커널 공간에서 실행되는 코드의 양을 최소화하는 데 도움이 됩니다.

모놀리식 커널에서의 대부분의 작업은 시스템 호출을 통해 이루어집니다.이러한 인터페이스는 일반적으로 표 구조로 유지되며 디스크 작업과 같은 커널 내의 일부 서브시스템에 액세스하는 인터페이스입니다.기본적으로 프로그램 내에서 호출이 이루어지며 요청의 체크된 복사본이 시스템 호출을 통해 전달됩니다.그러므로 여행하기에 그리 멀지 않습니다.모듈을 동적으로 로드할 수 있을 뿐만 아니라 사용자 지정이 용이하기 때문에 단일 리눅스 커널을 매우 작게 만들 수 있습니다.실제로 단일 플로피 디스크에 있는 수많은 유틸리티 및 기타 프로그램과 함께 사용할 수 있을 정도로 크기가 작은 버전도 있으며 여전히 완전한 기능을 갖춘 운영 체제(그 중 가장 인기 있는 것 중 하나는 muLinux입니다)를 제공).커널을 소형화할 수 있는 이러한 능력은 임베디드 시스템에서 리눅스를 사용하는 데 있어서도 급속한 성장을 이끌었습니다.

이러한 커널 유형은 운영 체제의 핵심 기능과 런타임에 모듈을 로드할 수 있는 장치 드라이버로 구성됩니다.기본 하드웨어에 대한 풍부하고 강력한 추상화 기능을 제공합니다.이들은 단순한 하드웨어 추상화의 소규모 집합을 제공하고 서버라는 애플리케이션을 사용하여 더 많은 기능을 제공합니다.이 접근 방식은 하드웨어를 통한 높은 수준의 가상 인터페이스를 정의하며, 슈퍼바이저 모드에서 실행되는 여러 모듈에서 프로세스 관리, 동시성 및 메모리 관리와 같은 운영 체제 서비스를 구현하기 위한 일련의 시스템 호출을 포함합니다.이 설계에는 다음과 같은 몇 가지 결점과 제한점이 있습니다.

  • 커널에서의 코딩은 부분적으로 (전체 기능 libc와 같은) 공통 라이브러리를 사용할 수 없고 gdb와 같은 소스 레벨 디버거를 사용해야 하기 때문에 어려울 수 있습니다.컴퓨터를 재부팅해야 하는 경우가 많습니다.이것은 단지 개발자들에게 편리함의 문제가 아닙니다.디버깅이 더 어렵고 어려움이 강해질수록 코드가 "버깅"될 가능성이 높아집니다.
  • 커널의 한 부분에 있는 버그는 강한 부작용을 가지고 있는데, 커널의 모든 기능은 모든 권한을 가지고 있기 때문에, 한 기능에 있는 버그는 커널의 전혀 관련이 없는 다른 부분이나 실행 중인 프로그램의 데이터 구조를 손상시킬 수 있습니다.
  • 커널은 종종 매우 커져서 유지하기가 어려워집니다.
  • 이러한 작업을 수행하는 모듈이 전체와 분리되어 있더라도 코드 통합이 빠듯하고 올바르게 수행되기 어렵습니다.
  • 모듈은 동일한 주소 공간에서 실행되기 때문에 버그로 인해 시스템 전체가 다운될 수 있습니다.
마이크로커널 접근 방식에서, 커널 자체는 서버, 디바이스 드라이버, GUI 서버 등과 같이 이전 커널 기능을 가정하는 별도의 프로그램의 실행을 허용하는 기본 기능만을 제공합니다.

마이크로커넬

마이크로커널()은 운영 체제 설계에 대한 접근 방식을 설명하는 용어로, 시스템의 기능이 전통적인 커널에서 벗어나 "최소" 커널을 통해 통신하는 "서버" 집합으로 이동하여 "시스템 공간"에 가능한 한 적게, "사용자 공간"에 가능한 한 적게 남겨둔다.특정 플랫폼이나 장치를 위해 설계된 마이크로커널은 작동하는 데 필요한 것만 갖게 됩니다.마이크로커널 접근 방식은 메모리 관리, 멀티태스킹프로세스 간 통신과 같은 최소한의 OS 서비스를 구현하기 위한 일련의 기본 또는 시스템 호출과 함께 하드웨어를 통한 단순한 추상화를 정의하는 것으로 구성됩니다.네트워킹과 같이 커널이 일반적으로 제공하는 서비스를 포함한 다른 서비스는 서버라고 하는 사용자 공간 프로그램에서 구현됩니다.마이크로커널은 단일 커널보다 유지보수가 쉽지만 시스템 호출과 컨텍스트 스위치 수가 많으면 일반 함수 호출보다 오버헤드가 많이 발생하기 때문에 시스템 속도가 느려질 수 있습니다.

커널 공간에는 IPC(Inter-Process Communication), 기본 스케줄러 또는 스케줄링 프리미티브, 기본 메모리 처리, 기본 I/O 프리미티브와 같이 실제로 권한 모드로 있어야 하는 부분만 있습니다.많은 중요 부품이 현재 사용자 공간에서 실행되고 있습니다.전체 스케줄러, 메모리 처리, 파일 시스템 및 네트워크 스택.마이크로 커널은 전통적인 "모놀리식" 커널 설계에 대한 반작용으로 발명되었으며, 이를 통해 모든 시스템 기능이 프로세서의 특별한 "시스템" 모드에서 실행되는 하나의 정적 프로그램에 포함되었습니다.마이크로커널에서는 하드웨어의 일부(꼭 전부는 아님)에 액세스하고 메모리를 관리하며 프로세스 간에 전달되는 메시지를 조정할 수 있는 등 가장 기본적인 작업만 수행됩니다.마이크로 커널을 사용하는 일부 시스템은 QNX와 HUD입니다.QNXHurd 사용자 세션의 경우 참조된 대로 시스템 자체 또는 보기의 전체 스냅샷이 될 수 있습니다.마이크로커널 아키텍처의 본질은 다음과 같은 장점을 보여줍니다.

  • 유지보수가 용이함
  • 패치는 별도의 인스턴스에서 테스트한 후 스왑 인하여 운영 인스턴스를 인수할 수 있습니다.
  • 커널을 재부팅할 필요 없이 빠른 개발 시간과 새로운 소프트웨어를 테스트할 수 있습니다.
  • 일반적으로 보다 지속성이 높아지면 한 인스턴스가 건망증에 걸리면 종종 작동 미러로 대체할 수 있습니다.

대부분의 마이크로커넬은 한 서버에서 다른 서버로의 요청을 처리하기 위해 메시지 전달 시스템을 사용합니다.메시지 전달 시스템은 일반적으로 마이크로커널과 함께 포트 기반으로 작동합니다.예를 들어, 더 많은 메모리 요청이 전송되면 마이크로커널과 요청이 전송된 포트가 열립니다.마이크로커널 내에서 단계가 시스템 호출과 유사합니다.그 근거는 시스템 아키텍처에 모듈화를 가져올 것이며, 이는 보다 깨끗한 시스템, 디버그 또는 동적 수정이 용이하고, 사용자 요구에 따라 맞춤화할 수 있으며, 성능이 향상될 것이라는 점이었습니다.GNU Hurd, MINIX, MkLinux, QNX 및 Redox OS같은 운영 체제의 일부입니다.마이크로커널은 그 자체로는 매우 작지만, 필요한 모든 보조 코드와 결합하여 실제로는 단일 커널보다 큰 경우가 많습니다.단일 커널 옹호자들은 또한 대부분의 운영 체제가 하드웨어와 직접 상호 작용하지 않는 마이크로 커널 시스템의 2층 구조가 시스템 효율 측면에서 상당한 비용을 발생시킨다고 지적합니다.이러한 커널 유형은 일반적으로 메모리 주소 공간 정의, 프로세스 간 통신(IPC) 및 프로세스 관리와 같은 최소한의 서비스만을 제공합니다.하드웨어 프로세스 실행과 같은 다른 기능은 마이크로커넬에서 직접 처리하지 않습니다.마이크로 커널 지지자들은 이러한 단일 커널이 커널의 오류로 인해 시스템 전체가 다운될 수 있다는 단점을 가지고 있다고 지적합니다.그러나 마이크로커널의 경우 커널 프로세스가 충돌할 경우 오류를 일으킨 서비스를 재시작하는 것만으로 시스템 전체의 충돌을 방지할 수 있습니다.

네트워킹과 같은 커널에 의해 제공되는 다른 서비스들은 서버로 지칭되는 사용자 공간 프로그램에서 구현됩니다.서버는 프로그램을 시작하고 중지하는 것만으로 운영 체제를 수정할 수 있습니다.네트워킹 지원이 없는 시스템의 경우 네트워킹 서버가 시작되지 않습니다.다양한 애플리케이션과 서버 간에 데이터를 이동하기 위해 커널을 드나드는 작업은 오버헤드를 발생시키며, 이는 단일 커널에 비해 마이크로 커널의 효율성에 해롭습니다.

그러나 마이크로커널에는 단점이 있습니다.일부는 다음과 같습니다.

  • 실행 중인 메모리 용량 증가
  • 인터페이스를 위한 소프트웨어가 더 많이 필요하므로 성능이 저하될 가능성이 있습니다.
  • 메시지 버그는 단일 커널에서 삭제된 복사본에 비해 이동 시간이 길기 때문에 수정하기가 더 어려울 수 있습니다.
  • 일반적으로 공정 관리는 매우 복잡할 수 있습니다.

마이크로커넬의 단점은 극도로 상황에 기반을 두고 있습니다.예를 들어, 소규모 단일 목적(및 중요) 시스템에서는 프로세스를 실행해야 하는 프로세스가 많지 않으면 프로세스 관리의 복잡성이 효과적으로 완화되기 때문에 이러한 시스템이 잘 작동합니다.

마이크로커널을 사용하면 운영 체제의 나머지 부분을 고급 언어로 작성된 일반 응용 프로그램으로 구현할 수 있으며 동일한 변경되지 않은 커널 위에 다른 운영 체제를 사용할 수 있습니다.운영 체제 간에 [25]동적으로 전환하고 동시에 둘 이상의 활성화를 가질 수도 있습니다.

단일 커널 대 마이크로 커널

컴퓨터 커널이 커짐에 따라 신뢰할 수 있는 컴퓨팅 기반의 크기와 취약성이 증가하고, 보안을 줄이는 것 외에도 메모리 사용량을 증가시키는 문제가 있습니다.이는 가상 메모리 시스템을 완벽하게 함으로써 어느 정도 완화되지만, 모든 컴퓨터 아키텍처가 가상 메모리를 [b]지원하는 것은 아닙니다.커널의 설치 공간을 줄이기 위해서는 수백만 줄의 코드를 가진 커널의 부분들 사이의 명백하지 않은 상호 의존성으로 인해 불필요한 코드를 신중하게 제거하기 위해 광범위한 편집이 수행되어야 합니다.

1990년대 초, 마이크로커널에 비해 모놀리식 커널의 다양한 단점 때문에, 모놀리식 커널은 사실상 모든 운영 체제 [citation needed]연구자들에 의해 구식으로 여겨졌습니다.결과적으로 리눅스를 마이크로커널이 아닌 단일 커널로 설계하는 것은 Linus TorvaldsAndrew Tanenbaum [35]사이의 유명한 논쟁의 주제였습니다.Tanenbaum에서 제시된 논쟁의 양 측면에는 장점이 있습니다.토론을 벌입니다.

성능

모놀리식 커널은 동일한 주소 공간(커널 공간)에 모든 코드를 갖도록 설계되어 있으며, 일부 개발자들은 [36]이 코드가 시스템의 성능을 높이기 위해 필요하다고 주장합니다.일부 개발자들은 또한 모놀리식 시스템이 [36]잘 쓰여지면 매우 효율적이라고 주장합니다.모노리식 모델은 일반적으로 메시지 [citation needed]전달에 기반을 둔 마이크로커널 설계의 느린 IPC 시스템보다는 공유 커널 메모리의 사용을 통해 더 효율적인[37] 경향이 있습니다.

마이크로커넬의 성능은 1980년대와 1990년대 [38][39]초반 모두 좋지 않았습니다.그러나 이러한 마이크로커넬의 성능을 실증적으로 측정한 연구들은 이러한 [38]비효율성의 원인을 분석하지 못했습니다.이 데이터에 대한 설명은 "folklore"에 맡겨졌습니다. 이는 "커널 모드"에서 "사용자 모드"로 전환되는 빈도가 증가하고 프로세스 간 통신 빈도가 증가하며 [38]컨텍스트 전환 빈도가 증가했기 때문이라고 가정합니다.

사실, 1995년에 추측했듯이 마이크로커널의 성능이 떨어지는 이유는 (1) 전체 마이크로커널 접근 방식의 실제 비효율성, (2) 해당 마이크로커널에 구현된 특정 개념, 그리고 (3) 해당 개념의 특정 구현이었습니다.따라서 효율적인 마이크로커널을 구축하기 위한 솔루션이 이전의 시도와 달리 올바른 구축 [38]기술을 적용하는 것인지에 대한 연구가 남아 있었습니다.

한편, 모놀리식[33] 커널의 설계를 유도하는 계층적 보호 도메인 아키텍처는 서로 다른 보호 레벨들 간의 상호작용이 있을 때마다(즉, 프로세스가 "사용자 모드" 및 "감독자 모드" 둘 모두에서 데이터 구조를 조작해야 하는 경우), 성능에 큰 단점이 있습니다.값별[40]메시지 복사가 필요하기 때문입니다.

하이브리드 커널 접근법은 단일 커널의 속도와 단순한 설계를 마이크로 커널의 모듈성과 실행 안전성을 결합합니다.

하이브리드(또는 모듈형) 커널

하이브리드 커널은 Microsoft Windows NT 3.1, NT 3.5, NT 3.51, NT 4.0, 2000, XP, Vista, 7, 8, 8.1 및 10과 같은 대부분의 상용 운영 체제에서 사용됩니다.애플의 macOS는 OSF/1마하 커널(OSFMK 7.3)[41]과 FreeB의 코드를 기반으로 한 XNU라는 하이브리드 커널을 사용합니다.SD의 모놀리식 커널.성능을 높이기 위해 커널 공간에 추가 코드를 포함한다는 점을 제외하면 마이크로 커널과 유사합니다.이러한 커널은 일부 개발자가 단일 커널과 마이크로 커널의 주요 이점을 모두 수용하기 위해 구현한 절충안을 나타냅니다.이러한 종류의 커널은 모놀리식 커널의 일부 속성을 가진 마이크로 커널의 확장입니다.모놀리식 커널과는 달리, 이러한 유형의 커널은 런타임 시 모듈을 자체적으로 로드할 수 없습니다.이는 기존 마이크로커널의 성능 오버헤드를 줄이기 위해 커널 공간에서 일부 서비스(: 네트워크 스택 또는 파일 시스템)를 실행하지만 커널 코드(예: 디바이스 드라이버)를 사용자 공간에서 서버로 실행한다는 것을 의미합니다.

기존의 많은 단일 커널들은 이제 적어도 모듈 기능을 추가(또는 사용)하고 있습니다.이러한 커널 중 가장 잘 알려진 것이 리눅스 커널입니다.모듈형 커널은 기본적으로 핵심 커널 바이너리에 내장된 부분이나 메모리에 필요에 따라 로드되는 바이너리를 포함할 수 있습니다.코드가 오염된 모듈은 실행 중인 커널을 불안정하게 할 가능성이 있습니다.많은 사람들이 마이크로 커널에 대해 논의할 때 이 점에 대해 혼란스러워 합니다.완전히 분리된 메모리 공간에서 마이크로커널용 드라이버를 작성하고 라이브로 "이동"하기 전에 테스트하는 것이 가능합니다.커널 모듈이 로드되면 필요한 것을 추가하여 모놀리식 부분의 메모리 공간에 액세스하므로 발생 가능한 오염에 대한 문을 엽니다.모듈형(또는 하이브리드) 커널의 몇 가지 이점은 다음과 같습니다.

  • 모듈 내에서 작동할 수 있는 드라이버의 개발 시간 단축.테스트를 위해 재부팅할 필요가 없습니다(커널이 불안정하지 않은 경우).
  • 온 디맨드 기능과 새로운 드라이버나 서브시스템과 같은 것을 위해 전체 커널을 다시 컴파일하는 데 시간을 소비합니다.
  • 타사 기술의 보다 빠른 통합(개발과 관련은 있지만 자체와 관련은 있음에도 불구하고).

모듈은 일반적으로 일종의 모듈 인터페이스를 사용하여 커널과 통신합니다.인터페이스는 일반화되어 있기 때문에(특정 운영 체제에만 해당) 항상 모듈을 사용할 수 있는 것은 아닙니다.종종 장치 드라이버는 모듈 인터페이스가 제공하는 것보다 더 많은 유연성을 필요로 할 수 있습니다.기본적으로 두 개의 시스템 호출이며, 현재 단일 커널에서 한 번만 수행하면 되는 안전 검사를 두 번 수행할 수도 있습니다.모듈식 접근방식의 단점은 다음과 같습니다.

  • 통과해야 할 인터페이스가 많아지면 버그가 증가할 가능성이 있습니다(이는 보안 구멍이 더 많다는 것을 의미합니다).
  • 모듈을 유지하는 것은 기호 차이와 같은 문제를 처리할 때 일부 관리자에게 혼란을 줄 수 있습니다.

나노커넬

나노커널은 인터럽트 컨트롤러나 타이머같은 가장 기본적인 서비스를 포함한 거의 모든 서비스를 장치 드라이버에 위임하여 기존의 [42]마이크로커널보다 커널 메모리 요구량을 훨씬 더 작게 만듭니다.

엑소커넬스

엑소커넬은 운영체제 설계에 대한 아직 실험적인 접근법입니다.이들은 원시 하드웨어의 보호 및 다중화로 기능을 제한하고 애플리케이션 개발을 위한 하드웨어 추상화를 제공하지 않는다는 점에서 다른 유형의 커널과 다릅니다.하드웨어 보호와 하드웨어 관리의 분리를 통해 애플리케이션 개발자는 각 특정 프로그램에 사용 가능한 하드웨어를 가장 효율적으로 사용하는 방법을 결정할 수 있습니다.

엑소커넬은 그 자체로 매우 작습니다.그러나 라이브러리 운영 체제(유니커널 참조)가 함께 제공되어 애플리케이션 개발자에게 기존 운영 체제의 기능을 제공합니다.이는 모든 사용자가 거의 처음부터 자신의 커널 나머지 부분을 작성하는 것으로 귀결되는데, 이는 매우 위험하고 복잡하며 상당히 부담스러운 과제입니다. 특히 시간 제약적인 생산 지향적 환경에서 특히 엑소커넬이 [citation needed]결코 성공하지 못한 이유입니다.엑소커널 기반 시스템의 가장 큰 장점은 여러 라이브러리 운영 체제를 통합할 수 있다는 점입니다. 예를 들어 고급 UI 개발을 위한 API와 실시간 제어를 위한 API를 각각 내보냅니다.

멀티커넬

멀티커널 운영 체제는 멀티 코어 시스템을 분산 시스템인 것처럼 독립적인 코어의 네트워크로 취급합니다.공유 메모리를 가정하지 않고 프로세스 간 통신을 메시지 [43][44]전달로 구현합니다.배럴피쉬는 멀티커널로 묘사된 최초의 운영체제였습니다.

커널개발이력

초기 운영 체제 커널

엄밀하게 말하면, 컴퓨터를 실행하는 데 운영 체제(따라서 커널)가 필요하지 않습니다.프로그램의 작성자가 하드웨어 추상화나 운영 체제 지원 없이 작업할 의사가 있다면 프로그램을 "베어 메탈" 기계에 직접 로드하고 실행할 수 있습니다.대부분의 초기 컴퓨터들은 1950년대와 1960년대 초에 이런 방식으로 작동했는데, 다른 프로그램의 실행 사이에 재설정되고 다시 로드되었습니다.결국, 프로그램 로더나 디버거같은 작은 보조 프로그램들은 실행 사이에 메모리에 남겨지거나 ROM으로부터 로드되었습니다.이것들이 개발되면서 초기 운영체제 커널이 된 것의 기초가 되었습니다."베어 메탈(bare metal)" 접근 방식은 오늘날에도 일부 비디오 게임 콘솔과 임베디드 [45]시스템에서 여전히 사용되고 있지만, 일반적으로 새로운 컴퓨터는 현대적인 운영 체제와 커널을 사용합니다.

1969년 RC 4000 멀티프로그래밍 시스템은 마이크로커널 접근법이라고 불리는 "다양한 목적의 운영 체제가 질서 있게 구축될 수 있는"[46] 작은 핵의 시스템 설계 철학을 도입했습니다.

시분할 운영 체제

Unix 이전의 10년 동안 컴퓨터는 엄청난 힘을 발휘했습니다. 컴퓨터 운영자들은 사람들이 자신의 컴퓨터에서 여가 시간을 사용할 수 있는 새로운 방법을 찾고 있을 정도였습니다.이 시대의 주요한 발전 중 하나는 시간 공유였습니다. 시간 공유를 통해 많은 사용자가 컴퓨터 시간을 조금 단축할 수 있었습니다. 이 속도로 각 사용자가 자신의 컴퓨터에 [47]더 느린 속도로 연결되는 것처럼 보입니다.

시분할 시스템의 발전은 많은 문제를 야기했습니다.하나는 사용자들이, 특히 시스템이 개발되고 있는 대학에서, CPU 시간을 늘리기 위해 시스템을 해킹하려는 으로 보인다는 것이었습니다.이러한 이유로 보안 [48]접근 통제는 1965년 멀틱스 프로젝트의 주요 초점이 되었습니다.진행 중인 또 다른 문제는 컴퓨팅 리소스를 적절하게 다루는 것이었습니다. 사용자는 대부분의 시간을 컴퓨터의 리소스를 실제로 사용하는 대신 단말기를 응시하고 무엇을 입력할지를 고민하는 데 할애했으며, 시분할 시스템은 이 기간 동안 활성 사용자에게 CPU 시간을 제공해야 합니다.마지막으로, 시스템은 일반적으로 메모리 계층 구조를 여러 계층에 걸쳐 제공하며, 이 값비싼 리소스를 분할하는 것이 가상 메모리 시스템의 큰 발전을 이끌었습니다.

아미가

코모도어 아미가는 1985년에 출시되었으며, 진보된 커널 아키텍처를 갖춘 최초의 가정용 컴퓨터 중 하나였습니다.아미가OS 커널의 실행 구성 요소인 exec.library는 마이크로커널 메시지 전달 설계를 사용하지만 graphics.library와 같이 하드웨어에 직접 액세스할 수 있는 다른 커널 구성 요소가 있습니다.메모리 보호가 없으며 커널은 거의 항상 사용자 모드로 실행됩니다.커널 모드에서는 특별한 동작만 실행되며, 사용자 모드 응용 프로그램에서는 운영 체제에 커널 모드에서 코드를 실행하도록 요청할 수 있습니다.

유닉스

유닉스 계열 시스템의 선/후계 계열 관계 다이어그램

유닉스의 설계 단계에서 프로그래머들은 계산의 목적이 데이터 [49]변환이라고 생각했기 때문에 모든 고급 장치를 파일로 모델링하기로 결정했습니다.

예를 들어, 프린터는 알려진 위치에서 "파일"로 표시되었습니다. – 데이터가 파일에 복사되면 인쇄됩니다.다른 시스템들은 비슷한 기능을 제공하기 위해 낮은 레벨에서 디바이스를 가상화하는 경향이 있었습니다. 즉, 디바이스와 파일 모두 낮은 레벨 개념의 인스턴스가 될 것입니다.파일 수준에서 시스템을 가상화하면 사용자가 기존 파일 관리 유틸리티 및 개념을 사용하여 전체 시스템을 조작할 수 있으므로 운영이 대폭 간소화됩니다.같은 패러다임의 확장으로, 유닉스는 프로그래머들이 일련의 작은 프로그램을 사용하여 파일을 조작할 수 있게 해줍니다. 파이프 개념을 사용하면 사용자가 단계적으로 작업을 완료하고 단일 목적 도구 체인을 통해 파일을 공급할 수 있습니다.결과는 같았지만 작은 프로그램을 사용하면 유연성은 물론 개발 및 사용 편의성이 크게 향상되어 사용자는 체인에서 프로그램을 추가하거나 제거함으로써 워크플로우를 수정할 수 있었습니다.

유닉스 모델에서 운영 체제는 두 부분으로 구성되어 있습니다. 첫째, 대부분의 운영을 주도하는 거대한 유틸리티 프로그램 모음, 둘째,[49] 프로그램을 실행하는 커널입니다.유닉스 하에서, 프로그래밍 관점에서 볼 때, 둘의 구별은 상당히 희박합니다; 커널은 슈퍼바이저 [c]모드로 실행되는 프로그램으로, 시스템의 나머지 부분을 구성하는 작은 유틸리티 프로그램들을 위한 프로그램 로더와 슈퍼바이저 역할을 하며, 이러한 프로그램들을 위한 잠금 및 I/O 서비스를 제공합니다; 그 밖에,커널은 사용자 공간에 전혀 개입하지 않았습니다.

수년간 컴퓨팅 모델이 변화하면서 유닉스는 모든 것을 파일이나 바이트 스트림으로 처리하는 것이 이전처럼 보편적으로 적용할 수 없게 되었습니다.단말기는 파일 또는 바이트 스트림으로 처리될 수 있으며, 이 스트림은 인쇄되거나 읽을 수 있지만 그래픽 사용자 인터페이스의 경우에도 마찬가지인 것으로 보입니다.네트워킹은 또 다른 문제를 야기했습니다.네트워크 통신을 파일 액세스와 비교할 수 있다 하더라도 낮은 수준의 패킷 지향 아키텍처는 전체 파일이 아닌 개별 데이터 청크를 처리했습니다.컴퓨터의 기능이 증가함에 따라, 유닉스는 코드로 점점 더 어수선해졌습니다.또한 유닉스 커널의 모듈화가 광범위하게 [50]확장 가능하기 때문입니다.70년대와 80년대에 커널은 코드 라인이 100,000개였던 반면, 리눅스와 같은 커널은 GNU와 같은 현대 유닉스 후속 제품의 라인이 1,300만 [51]개 이상입니다.

현대의 유닉스 파생 제품은 일반적으로 모듈 로딩 모놀리식 커널을 기반으로 합니다.그 예로는 GNU, IBM AIX의 여러 배포판에 있는 리눅스 커널과 FreeBSD, DragonFly BSD, OpenBSD, NetBSD, macOS와 같은 버클리 소프트웨어 배포 변종 커널이 있습니다.이러한 대안 이외에도 아마추어 개발자들은 대부분 리눅스, FreeBSD, DragonflyBSD, OpenBSD 또는 NetBSD 커널과 많은 기능을 공유하고 [52]호환되는 자체 작성 취미 커널로 채워지는 활발한 운영 체제 개발 커뮤니티를 유지하고 있습니다.

클래식 맥 OS 및 맥 OS

애플1984년 매킨토시 개인용 컴퓨터와 함께 제공되는 클래식 맥 OS를 처음 출시했습니다.애플은 맥 OS 8.6에서 나노커널 디자인으로 옮겼습니다. 이에 맞서는 현대 맥 OS(원래 이름은 맥 OS X)는 다윈을 기반으로 하는데, 다윈은 4.3을 결합하여 만든 XNU라는 하이브리드 커널을 사용합니다.BSD 커널과 마하 커널.[53]

마이크로소프트 윈도우

마이크로소프트 윈도우는 1985년 MS-DOS의 추가 기능으로 처음 출시되었습니다. 다른 운영 체제에 의존하기 때문에 윈도우 95 이전의 윈도우 초기 출시는 운영 체제와 혼동하지 않는 운영 환경으로 간주되었습니다.이 제품군은 1980년대와 1990년대에 윈도우 9x 시리즈에 32비트 어드레싱과 선제적 멀티태스킹이 추가되면서 계속 발전했지만 2000년에 윈도우 Me가 출시되면서 끝이 났습니다.

마이크로소프트는 또한 매우 유사한 인터페이스를 가지고 있지만 고급 사용자와 비즈니스 사용자를 위한 운영 체제인 윈도우 NT를 개발했습니다.이 라인은 1993년 윈도우 NT 3.1 출시와 함께 시작되었으며 2001년 10월 윈도우 XP 출시와 함께 일반 사용자들에게 선보였으며, 윈도우 9x를 완전히 다른 훨씬 더 정교한 운영 체제로 대체했습니다.이것은 윈도우 11에서 계속되는 라인입니다.

Windows NT의 커널 아키텍처는 클라이언트/서버 계층화된 하위 시스템 [54]모델과 함께 커널 자체에 Windows Manager 및 IPC Manager와 같은 작업이 포함되어 있기 때문에 하이브리드 커널로 간주됩니다.윈도우 NT 커널이 마하 마이크로커널의 영향을 받았기 때문에 수정된 마이크로커널로 설계되었지만 순수 마이크로커널의 모든 기준을 충족시키지는 못했습니다.

IBM 슈퍼바이저

슈퍼바이저 프로그램(supervisory program) 또는 슈퍼바이저(supervisory program)는 일반적으로 운영 체제의 일부인 컴퓨터 프로그램으로, 다른 루틴의 실행을 제어하고 작업 스케줄링, 입출력 작업, 오류 동작 및 이와 유사한 기능을 제어하며 데이터 처리 시스템의 작업 흐름을 제어하는 프로그램입니다.

역사적으로 이 용어는 OS/360부터 시작하는 IBM의 메인프레임 운영 체제 계열과 본질적으로 연관되어 있었습니다.다른 운영 체제에서는 일반적으로 슈퍼바이저를 커널이라고 부릅니다.

1970년대에 IBM은 하드웨어에서 슈퍼바이저 상태를 더 추상화하여 완전한 가상화를 가능하게 하는 하이퍼바이저, 즉 동일한 머신에서 여러 운영 체제를 완전히 독립적으로 실행할 수 있는 용량을 제공했습니다.그래서 이러한 시스템을 처음으로 가상 머신(Virtual Machine) 또는 VM이라고 불렀습니다.

마이크로커넬 개발

카네기 멜론 대학의 리차드 라시드가 개발한 마하가 가장 잘 알려진 범용 마이크로커널이지만, 다른 마이크로커널들은 더 구체적인 목적을 가지고 개발되었습니다.L4 마이크로커널 계열(주로 L3와 L4 커널)은 마이크로커널이 반드시 [55]느린 것은 아니라는 것을 증명하기 위해 만들어졌습니다.FiascoPistachio와 같은 최신 구현은 별도의 주소 [56][57]공간에서 다른 L4 프로세스 옆에서 Linux를 실행할 수 있습니다.

또한 QNX는 임베디드 [58]시스템에 주로 사용되는 마이크로커널이며 오픈소스 소프트웨어인 MINIX는 원래 교육용으로 개발되었으나 현재는 신뢰성이 높고 자가 치유가능한 마이크로커널 OS에 초점을 맞추고 있습니다.

참고 항목

메모들

  1. ^ 컴퓨터 아키텍처에 따라 다를 수 있습니다.
  2. ^ 가상 주소 지정은 일반적으로 내장 메모리 관리 장치를 통해 이루어집니다.
  3. ^ 최고 권한 레벨은 슈퍼바이저 모드, 커널 모드, CPL0, DPL0, 링 0 등 다양한 아키텍처 전반에 걸쳐 다양한 이름을 갖습니다.자세한 내용은 보호 링을 참조하십시오.

참고문헌

  1. ^ a b "Kernel". Linfo. Bellevue Linux Users Group. Archived from the original on 8 December 2006. Retrieved 15 September 2016.
  2. ^ Randal E. Bryant; David R. O’Hallaron (2016). Computer Systems: A Programmer's Perspective (Third ed.). Pearson. p. 17. ISBN 978-0134092669.
  3. ^ cf. 데몬(컴퓨팅)
  4. ^ a b 로치 2004
  5. ^ a b c d e f g Wulf 1974 pp.337–345
  6. ^ a b 실버샤츠 1991
  7. ^ Tanenbaum, Andrew S. (2008). Modern Operating Systems (3rd ed.). Prentice Hall. pp. 50–51. ISBN 978-0-13-600663-3. . . . nearly all system calls [are] invoked from C programs by calling a library procedure . . . The library procedure . . . executes a TRAP instruction to switch from user mode to kernel mode and start execution . . .
  8. ^ 데닝 1976
  9. ^ Swift 2005, p.29 인용문: "격리, 자원 통제, 의사결정 검증(체크), 오류 복구"
  10. ^ 슈뢰더 72
  11. ^ a b 린덴76
  12. ^ Eranian, Stephane; Mosberger, David (2002). "Virtual Memory in the IA-64 Linux Kernel". IA-64 Linux Kernel: Design and Implementation. Prentice Hall PTR. ISBN 978-0-13-061014-0.
  13. ^ Silbershatz & Galvin, 운영체제 개념, 제4판, pp. 445 & 446
  14. ^ Hoch, Charles; J. C. Browne (July 1980). "An implementation of capabilities on the PDP-11/45". ACM SIGOPS Operating Systems Review. 14 (3): 22–32. doi:10.1145/850697.850701. S2CID 17487360.
  15. ^ a b Schneider F., Morrissett G. (Cornell University) and Harper R. (Carnegie Mellon University). "A Language-Based Approach to Security" (PDF). Archived (PDF) from the original on 2018-12-22.{{cite web}}: CS1 maint: 작성자 매개변수 사용 (링크)
  16. ^ a b c Loscocco, P. A.; Smalley, S. D.; Muckelbauer, P. A.; Taylor, R. C.; Turner, S. J.; Farrell, J. F. (October 1998). "The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments". Proceedings of the 21st National Information Systems Security Conference. pp. 303–314. Archived from the original on 2007-06-21.
  17. ^ Lepreau, Jay; Ford, Bryan; Hibler, Mike (1996). "The persistent relevance of the local operating system to global applications". Proceedings of the 7th workshop on ACM SIGOPS European workshop Systems support for worldwide applications - EW 7. pp. 133–140. doi:10.1145/504450.504477. ISBN 9781450373395. S2CID 10027108.
  18. ^ Anderson, J. (October 1972). Computer Security Technology Planning Study (PDF) (Report). Vol. II. Air Force Electronic Systems Division. ESD-TR-73-51, Vol. II. Archived (PDF) from the original on 2011-07-21.
  19. ^ Jerry H. Saltzer; Mike D. Schroeder (September 1975). "The protection of information in computer systems". Proceedings of the IEEE. 63 (9): 1278–1308. CiteSeerX 10.1.1.126.9257. doi:10.1109/PROC.1975.9939. S2CID 269166. Archived from the original on 2021-03-08. Retrieved 2007-07-15.
  20. ^ "Fine-grained kernel isolation". mars-research.github.io. Retrieved 15 September 2022.
  21. ^ Fetzer, Mary. "Automatic device driver isolation protects against bugs in operating systems". Pennsylvania State University via techxplore.com. Retrieved 15 September 2022.
  22. ^ Huang, Yongzhe; Narayanan, Vikram; Detweiler, David; Huang, Kaiming; Tan, Gang; Jaeger, Trent; Burtsev, Anton (2022). "KSplit: Automating Device Driver Isolation" (PDF). Retrieved 15 September 2022.
  23. ^ Jonathan S. Shapiro; Jonathan M. Smith; David J. Farber (1999). "EROS". ACM Sigops Operating Systems Review. 33 (5): 170–185. doi:10.1145/319344.319163.
  24. ^ Dijkstra, E.W. 순차 프로세스 협력.수학과,테크놀로지 U., 아인트호벤, 1965년 9월
  25. ^ a b c d e 브린치 한센 70 pp.238-241
  26. ^ Harrison, M. C.; Schwartz, J. T. (1967). "SHARER, a time sharing system for the CDC 6600". Communications of the ACM. 10 (10): 659–665. doi:10.1145/363717.363778. S2CID 14550794.
  27. ^ Huxtable, D. H. R.; Warwick, M. T. (1967). Dynamic Supervisors – their design and construction. pp. 11.1–11.17. doi:10.1145/800001.811675. ISBN 9781450373708. S2CID 17709902. Archived from the original on 2020-02-24. Retrieved 2007-01-07.
  28. ^ 바이아르디 1988
  29. ^ a b 레빈 75
  30. ^ 데닝 1980
  31. ^ Nehmer, Jürgen (1991). "The Immortality of Operating Systems, or: Is Research in Operating Systems still Justified?". Lecture Notes In Computer Science; Vol. 563. Proceedings of the International Workshop on Operating Systems of the 90s and Beyond. pp. 77–83. doi:10.1007/BFb0024528. ISBN 3-540-54987-0. The past 25 years have shown that research on operating system architecture had a minor effect on existing main stream [sic] systems.
  32. ^ Levy 84, p.1 인용문: "컴퓨터 응용 프로그램의 복잡성이 해마다 증가하고 있지만 응용 프로그램의 기본 하드웨어 아키텍처는 수십 년 동안 변하지 않았습니다."
  33. ^ a b c Levy 84, p.1 인용문: "전통적인 아키텍처는 단일한 특권적인 운영 방식을 지원합니다.이러한 구조는 단일화된 설계로 이어집니다. 보호가 필요한 모든 모듈은 단일 운영 체제 커널의 일부여야 합니다.대신 보호된 도메인 내에서 모듈을 실행할 수 있다면, 시스템은 모든 사용자가 확장할 수 있는 독립적인 모듈 집합으로 구축될 수 있습니다."
  34. ^ a b "Open Sources: Voices from the Open Source Revolution". 1-56592-582-3. 29 March 1999. Archived from the original on 1 February 2020. Retrieved 24 March 2019.
  35. ^ Torvalds와 Tanenbaum 사이의 논쟁에 대한 기록은 dina.dk Archived 2012-10-03 at the Wayback Machine, groups.google.com Archived 2013-05-26 at the Wayback Machine, oreilly.com Archived 2014-09-21 and Andrew Tanenbaum's 웹사이트 Archived 2015-08-05 at the Wayback Machine에서 확인할 수 있습니다.
  36. ^ a b Matthew Russell. "What Is Darwin (and How It Powers Mac OS X)". O'Reilly Media. Archived from the original on 2007-12-08. Retrieved 2008-12-09. The tightly coupled nature of a monolithic kernel allows it to make very efficient use of the underlying hardware [...] Microkernels, on the other hand, run a lot more of the core processes in userland. [...] Unfortunately, these benefits come at the cost of the microkernel having to pass a lot of information in and out of the kernel space through a process known as a context switch. Context switches introduce considerable overhead and therefore result in a performance penalty.
  37. ^ "Operating Systems/Kernel Models - Wikiversity". en.wikiversity.org. Archived from the original on 2014-12-18. Retrieved 2014-12-18.
  38. ^ a b c d 리트케 95
  39. ^ 하르티그 97
  40. ^ Hansen 73, 섹션 7.3 p.233 "서로 다른 보호 수준 사이의 상호작용은 값에 의한 메시지 전송을 필요로 합니다."
  41. ^ Magee, Jim. WWDC 2000 Session 106 – Mac OS X: Kernel. 14 minutes in. Archived from the original on 2021-10-30.
  42. ^ "KeyKOS Nanokernel Architecture". Archived from the original on 2011-06-21.
  43. ^ 바우만 등, "멀티커널: 확장 가능한 멀티코어 시스템을 위한 새로운 OS 아키텍처" 제22회 운영체제 원리 심포지엄(2009), http://research.microsoft.com/pubs/101903/paper.pdf
  44. ^ Barrelfish 운영체제, http://www.barrelfish.org/ .
  45. ^ 볼: 내장형 마이크로프로세서 설계, 페이지 129
  46. ^ Hansen 2001 (os), pp.17–18
  47. ^ "BSTJ version of C.ACM Unix paper". bell-labs.com. Archived from the original on 2005-12-30. Retrieved 2006-08-17.
  48. ^ Corbató, F. J.; Vissotsky, V. A. Introduction and Overview of the Multics System. 1965 Fall Joint Computer Conference. Archived from the original on 2011-07-09.
  49. ^ a b "The Single Unix Specification". The open group. Archived from the original on 2016-10-04. Retrieved 2016-09-29.
  50. ^ "Unix's Revenge". asymco.com. 29 September 2010. Archived from the original on 9 November 2010. Retrieved 2 October 2010.
  51. ^ Wheeler, David A. (October 12, 2004). "Linux Kernel 2.6: It's Worth More!".
  52. ^ 이 커뮤니티는 주로 Wayback Machine에서 Bona Fide OS Development Archived 2022-01-17, Wayback Machine에서 Mega-Tokyo Message Board Archived 2022-01-25 및 기타 운영 체제 매니아 웹 사이트에 모입니다.
  53. ^ Singh, Amit (December 2003). "XNU: The Kernel". Archived from the original on 2011-08-12.
  54. ^ "Windows - Official Site for Microsoft Windows 10 Home & Pro OS, laptops, PCs, tablets & more". windows.com. Archived from the original on 2011-08-20. Retrieved 2019-03-24.
  55. ^ "The L4 microkernel family - Overview". os.inf.tu-dresden.de. Archived from the original on 2006-08-21. Retrieved 2006-08-11.
  56. ^ "The Fiasco microkernel - Overview". os.inf.tu-dresden.de. Archived from the original on 2006-06-16. Retrieved 2006-07-10.
  57. ^ Zoller (inaktiv), Heinz (7 December 2013). "L4Ka - L4Ka Project". www.l4ka.org. Archived from the original on 19 April 2001. Retrieved 24 March 2019.
  58. ^ "QNX Operating Systems". blackberry.qnx.com. Archived from the original on 2019-03-24. Retrieved 2019-03-24.

원천

추가열람

외부 링크