본문으로 이동

커널 (컴퓨팅)

위키백과, 우리 모두의 백과사전.
응용 소프트웨어가 컴퓨터의 하드웨어와 연결되는 방식을 단순화하여 보여주는 그림

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

커널의 핵심 코드는 일반적으로 응용 소프트웨어나 운영체제의 다른 덜 중요한 부분으로부터의 접근이 보호되는 별도의 메모리 영역에 로드된다. 커널은 프로세스 스케줄링, 하드 디스크와 같은 하드웨어 장치 관리, 인터럽트 처리와 같은 작업을 이 보호된 커널 공간에서 수행한다. 반면, 브라우저, 워드 프로세서, 오디오 또는 비디오 플레이어와 같은 응용 프로그램은 별도의 메모리 영역인 사용자 공간을 사용한다. 이는 사용자 데이터와 커널 데이터가 서로 간섭하여 불안정성과 느려짐을 유발하는 것을 방지하며,[2] 오작동하는 응용 프로그램이 다른 응용 프로그램에 영향을 주거나 전체 운영체제를 충돌시키는 것을 방지한다. 커널이 응용 프로그램의 주소 공간에 포함되는 시스템에서도 메모리 보호를 사용하여 권한이 없는 응용 프로그램이 커널을 수정하는 것을 막는다.

커널의 인터페이스는 저수준 추상화 계층이다. 프로세스가 커널에 서비스를 요청할 때는 일반적으로 래퍼 함수를 통해 시스템 호출을 호출해야 한다.

커널 아키텍처 설계에는 여러 가지 방식이 있다. 모놀리식 커널은 속도를 위해 전체가 하나의 주소 공간에서 실행되며 CPU는 슈퍼바이저 모드에서 작동한다. 마이크로커널은 회복탄력성과 모듈화를 위해 대부분의 서비스를 사용자 프로세스처럼 사용자 공간에서 실행한다.[4][5] MINIX 3는 마이크로커널 설계의 대표적인 예이다. 리눅스 커널과 같은 일부 커널은 런타임에 적재 가능 커널 모듈을 삽입하거나 제거할 수 있기 때문에 모놀리식인 동시에 모듈형이기도 하다.

컴퓨터 시스템의 이 핵심 구성 요소는 프로그램을 실행할 책임이 있다. 커널은 실행 중인 여러 프로그램 중 어느 것을 언제 프로세서에 할당할지 결정하는 책임을 진다.

랜덤 액세스 메모리

[편집]

랜덤 액세스 메모리(RAM)는 프로그램 명령어와 데이터를 모두 저장하는 데 사용된다.[a] 일반적으로 프로그램이 실행되려면 이 둘 모두가 메모리에 존재해야 한다. 종종 여러 프로그램이 메모리 접근을 원하게 되며, 컴퓨터가 가진 것보다 더 많은 메모리를 요구하는 경우가 잦다. 커널은 각 프로세스가 어떤 메모리를 사용할 수 있는지 결정하고, 사용 가능한 메모리가 부족할 때 어떻게 할지 결정할 책임이 있다.

입출력 장치

[편집]

I/O 장치에는 키보드, 마우스, 디스크 드라이브, 프린터, USB 장치, 네트워크 어댑터, 디스플레이 장치와 같은 주변기기가 포함되지만 이에 국한되지 않는다. 커널은 응용 프로그램이 이러한 장치를 편리하게 사용할 수 있는 방법을 제공하며, 일반적으로 커널에 의해 추상화되므로 응용 프로그램은 세부적인 구현 방식을 알 필요가 없다.

리소스 관리

[편집]

리소스 관리에서 필요한 핵심 요소는 실행 영역(주소 공간)을 정의하고 해당 영역 내의 자원에 대한 접근을 조정하는 보호 메커니즘을 사용하는 것이다.[6] 또한 커널은 동기화 및 프로세스 간 통신(IPC)을 위한 방법을 제공한다. 이러한 구현은 커널 내부에 위치할 수도 있고, 커널이 실행 중인 다른 프로세스에 의존할 수도 있다. 커널이 각 기능에 대한 접근을 제공하기 위해 IPC를 제공해야 하지만, 커널은 실행 중인 프로그램이 이러한 기능에 접근하도록 요청하는 방법도 제공해야 한다. 커널은 프로세스나 스레드 간의 문맥 교환도 담당한다.

메모리 관리

[편집]

커널은 시스템의 메모리에 대한 완전한 접근 권한을 가지며 프로세스가 필요할 때 이 메모리에 안전하게 접근하도록 허용해야 한다. 종종 이를 위한 첫 번째 단계는 페이징 및 세그멘테이션을 통해 달성되는 가상 주소 지정이다. 가상 주소 지정을 통해 커널은 특정 물리적 주소가 다른 주소(가상 주소)인 것처럼 보이게 할 수 있다. 가상 주소 공간은 프로세스마다 다를 수 있다. 즉, 한 프로세스가 특정 (가상) 주소에서 접근하는 메모리와 다른 프로세스가 같은 주소에서 접근하는 메모리가 서로 다를 수 있다. 이를 통해 모든 프로그램은 자신이 실행 중인 유일한 프로그램인 것처럼 동작할 수 있으며, 결과적으로 응용 프로그램이 서로 충돌하는 것을 방지한다.[7]

많은 시스템에서 프로그램의 가상 주소는 현재 메모리에 없는 데이터를 참조할 수 있다. 가상 주소 지정이 제공하는 간접 참조 계층을 통해 운영체제는 주 메모리(RAM)에 남아 있어야 할 데이터를 하드 드라이브와 같은 다른 데이터 저장소에 보관할 수 있다. 결과적으로 운영체제는 프로그램이 시스템의 물리적 가용 메모리보다 더 많은 메모리를 사용하도록 허용할 수 있다. 프로그램이 현재 RAM에 없는 데이터를 필요로 할 때 CPU는 커널에 이를 알리고, 커널은 비활성 메모리 블록의 내용을 디스크에 쓰고(필요한 경우) 프로그램이 요청한 데이터로 교체하여 응답한다. 그런 다음 프로그램은 중단된 지점부터 다시 시작할 수 있다. 이 방식을 일반적으로 요구 페이징이라 한다.

가상 주소 지정은 또한 메모리를 두 개의 분리된 영역으로 나누어 가상 파티션을 생성할 수 있게 한다. 하나는 커널을 위해 예약된 영역(커널 공간)이고 다른 하나는 응용 프로그램을 위한 영역(사용자 공간)이다. 프로세서는 응용 프로그램이 커널 메모리를 주소 지정하는 것을 허용하지 않으므로 응용 프로그램이 실행 중인 커널을 손상시키는 것을 방지한다. 메모리 공간의 이러한 기본적인 파티션은 실제 범용 커널의 현재 설계에 많은 기여를 했으며 대부분의 시스템에서 보편적이지만, 일부 연구용 커널(예: 싱귤래러티)은 다른 접근 방식을 취한다.

장치 관리

[편집]

유용한 기능을 수행하기 위해 프로세스는 컴퓨터에 연결된 주변기기에 접근해야 하며, 이는 커널이 장치 드라이버를 통해 제어한다. 장치 드라이버는 운영체제를 대신하여 하드웨어 장치를 캡슐화, 모니터링 및 제어(하드웨어/소프트웨어 인터페이스를 통해)하는 컴퓨터 프로그램이다. 장치 드라이버는 특정 하드웨어를 제어하고 통신하는 방법에 대한 API, 절차 및 정보를 운영체제에 제공한다. 장치 드라이버는 모든 OS와 그 응용 프로그램에 있어 중요하고 필수적인 의존 요소이다. 드라이버의 설계 목표는 추상화이며, 드라이버의 기능은 운영체제가 명령한 추상 함수 호출(프로그래밍 호출)을 장치별 호출로 변환하는 것이다. 이론적으로 장치는 적절한 드라이버와 함께 올바르게 작동해야 한다. 장치 드라이버는 호스트 어댑터, 그래픽 카드, 사운드 카드, 프린터, 이미지 스캐너, 모뎀 및 네트워크 인터페이스 컨트롤러 등에 사용된다.

하드웨어 수준에서 장치 드라이버의 일반적인 추상화는 다음과 같다.

  • 직접 인터페이스
  • 비디오 바이오스와 같은 고수준 인터페이스 사용
  • 저수준 장치 드라이버 사용 (디스크 드라이버를 사용하는 파일 시스템 드라이버)
  • 완전히 다른 작업을 수행하면서 하드웨어 작업을 시뮬레이션

소프트웨어 수준에서 장치 드라이버의 추상화는 다음과 같다.

  • 운영체제가 하드웨어 자원에 직접 접근하도록 허용
  • 기본 요소(primitive)만 구현
  • TWAIN과 같은 드라이버 이외의 소프트웨어를 위한 인터페이스 구현
  • 언어 구현 (종종 포스트스크립트와 같은 고수준 언어)

예를 들어, 사용자에게 화면의 무언가를 보여주기 위해 응용 프로그램은 커널에 요청을 보내고, 커널은 이 요청을 디스플레이 드라이버로 전달하며, 드라이버는 실제로 문자를 그리거나 픽셀을 배치할 책임을 진다.[7]

커널은 사용 가능한 장치 목록을 유지해야 한다. 이 목록은 사전에 알려져 있거나(예: 사용 가능한 하드웨어가 변경되면 커널이 다시 작성되는 임베디드 시스템), 사용자에 의해 구성되거나(이전 PC 및 개인용으로 설계되지 않은 시스템에서 일반적임), 운영체제에 의해 실행 시간에 감지될 수 있다(일반적으로 플러그 앤 플레이라고 함). 플러그 앤 플레이 시스템에서 장치 관리자는 먼저 PCI 버스 또는 USB와 같은 다양한 주변기기 버스를 스캔하여 설치된 장치를 감지한 다음 적절한 드라이버를 검색한다.

장치 관리는 매우 운영체제 특화된 주제이므로 이러한 드라이버는 커널 설계 종류에 따라 다르게 처리되지만, 어떤 경우든 커널은 드라이버가 포트나 메모리 위치를 통해 물리적으로 장치에 접근할 수 있도록 입출력을 제공해야 한다. 일부 설계에서는 접근 과정에 문맥 교환이 포함되어 작업이 매우 CPU 집약적이 되고 상당한 성능 오버헤드를 유발할 수 있으므로, 장치 관리 시스템을 설계할 때 중요한 결정을 내려야 한다.

시스템 호출

[편집]

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

시스템 호출은 응용 프로그램이 운영체제에 서비스를 요청하는 데 사용하는 메커니즘이다. 시스템 호출은 프로세서가 모드를 변경하도록 하는 기계어 명령어를 사용한다. 예를 들어 슈퍼바이저 모드에서 보호 모드로 변경하는 것 등이 있다. 여기서 운영체제는 하드웨어 장치에 접근하거나 메모리 관리 장치를 사용하는 것과 같은 작업을 수행한다. 일반적으로 운영체제는 운영체제와 일반 사용자 프로그램 사이에 위치한 라이브러리를 제공한다. 보통 Glibc나 Windows API와 같은 C 라이브러리이다. 라이브러리는 정보를 커널에 전달하고 슈퍼바이저 모드로 전환하는 저수준 세부 사항을 처리한다. 시스템 호출에는 close, open, read, wait, write 등이 포함된다.

실제로 유용한 작업을 수행하려면 프로세스가 커널이 제공하는 서비스에 접근할 수 있어야 한다. 이는 각 커널마다 다르게 구현되지만, 대부분 관련 커널 기능을 호출하는 C 라이브러리나 API를 제공한다.[8]

커널 기능을 호출하는 방식은 커널마다 다르다. 메모리 격리가 사용 중인 경우 사용자 프로세스가 커널을 직접 호출하는 것은 불가능하다. 이는 프로세서의 접근 제어 규칙을 위반하기 때문이다. 몇 가지 가능성은 다음과 같다.

  • 인터럽트 사용.[e] 이 방법은 대부분의 하드웨어에서 사용 가능하므로 매우 흔하다.
  • 콜 게이트 사용. 콜 게이트는 프로세서가 알고 있는 위치의 커널 메모리 목록에 커널이 저장한 특수 주소이다. 프로세서가 해당 주소로의 호출을 감지하면 접근 위반을 일으키는 대신 대상 위치로 리디렉션한다. 이는 하드웨어 지원이 필요하지만 관련 하드웨어는 매우 일반적이다.
  • 특수 시스템 호출 명령어 사용. 이 기술은 일반적인 아키텍처(특히 X86)에는 없을 수 있는 특수 하드웨어 지원이 필요하다. 그러한 아키텍처의 경우 인터럽트나 콜 게이트가 사용된다. 하지만 최근의 X86 프로세서 모델에는 시스템 호출 명령어가 추가되었으며 일부 PC용 운영체제는 사용 가능할 때 이를 활용한다.
  • 메모리 기반 큐 사용. 많은 요청을 하지만 각 요청의 결과를 기다릴 필요가 없는 응용 프로그램은 커널이 요청을 찾기 위해 주기적으로 스캔하는 메모리 영역에 요청 세부 정보를 추가할 수 있다.

커널 설계 결정

[편집]

보호

[편집]

커널 설계에서 중요한 고려 사항은 결함(장애 허용) 및 악의적인 동작(보안)으로부터의 보호를 지원하는 것이다. 이 두 측면은 일반적으로 명확하게 구분되지 않으며 커널 설계에서 이러한 구분을 채택하면 계층적 보호 구조를 거부하게 된다.[6]

커널이 제공하는 메커니즘이나 정책은 다음을 포함한 여러 기준에 따라 분류될 수 있다.

  • 정적(컴파일 타임에 강제)인지 동적(런타임에 강제)인지 여부
  • 선점형인지 사후 탐지형인지 여부
  • 하드웨어 지원 기반인지 언어 기반인지 여부
  • 개방형 메커니즘인지 바인딩 정책인지 여부
  • 만족하는 보호 원칙에 따름 (예: 데닝[12][13])
  • 그 외 다수.

계층적 보호 도메인에 대한 지원[14]은 일반적으로 CPU 모드를 사용하여 구현된다.

많은 커널은 "기능(capabilities)"을 구현한다. 즉, 커널이 관리하는 기본 객체에 제한된 접근을 허용하기 위해 사용자 코드에 제공되는 객체이다. 일반적인 예는 파일 처리이다. 파일은 영구 저장 장치에 저장된 정보의 표현이다. 커널은 읽기, 쓰기, 삭제 또는 실행을 포함하여 다양한 작업을 수행할 수 있지만 사용자 수준 응용 프로그램은 이러한 작업 중 일부만 수행하도록 허용될 수 있다(예: 파일 읽기만 가능). 이 방식의 일반적인 구현은 커널이 응용 프로그램에 객체(일반적으로 "파일 핸들"이라 함)를 제공하고 응용 프로그램이 해당 객체에 작업을 호출하면 커널이 요청 시점에 타당성을 확인하는 것이다. 이러한 시스템은 커널이 관리하는 모든 객체와 다른 사용자 응용 프로그램이 제공하는 객체까지 포함하도록 확장될 수 있다.

기능에 대한 하드웨어 지원을 제공하는 효율적이고 간단한 방법은 모든 메모리 접근에 대해 접근 권한을 확인하는 책임을 메모리 관리 장치(MMU)에 위임하는 것인데, 이를 기능 기반 주소 지정이라 한다.[15] 대부분의 상용 컴퓨터 아키텍처는 기능에 대한 그러한 MMU 지원이 부족하다. CHERI 프로젝트는 여러 아키텍처에 대한 기능 기반 메커니즘을 개발하고 있다.

대안적인 접근 방식은 일반적으로 지원되는 계층적 도메인을 사용하여 기능을 시뮬레이션하는 것이다. 이 접근 방식에서 각 보호 대상 객체는 응용 프로그램이 접근할 수 없는 주소 공간에 있어야 하며, 커널도 그러한 메모리에 기능 목록을 유지한다. 응용 프로그램이 기능으로 보호되는 객체에 접근해야 할 때 시스템 호출을 수행하면 커널은 응용 프로그램의 기능이 요청된 작업을 수행할 권한을 부여하는지 확인하고, 허용된다면 접근을 수행한다(직접 수행하거나 다른 사용자 수준 프로세스에 요청을 위임). 주소 공간 전환의 성능 비용으로 인해 객체 간 복잡한 상호 작용이 있는 시스템에서 이 접근 방식의 실용성은 제한되지만, 자주 접근하지 않거나 빠르게 작동할 것으로 예상되지 않는 객체에 대해서는 현재 운영체제에서 사용된다.[16][17]

펌웨어가 보호 메커니즘을 지원하지 않는 경우, 페이지 테이블을 조작하여 기능을 시뮬레이션하는 등 더 높은 수준에서 보호를 시뮬레이션할 수 있지만 성능에 영향이 있다.[18] 그러나 언어 기반 보호를 사용하기로 선택한 시스템의 경우 하드웨어 지원 부족은 문제가 되지 않을 수 있다.[19]

중요한 커널 설계 결정은 보안 메커니즘과 정책을 구현해야 하는 추상화 수준을 선택하는 것이다. 커널 보안 메커니즘은 더 높은 수준의 보안을 지원하는 데 중요한 역할을 한다.[15][20][21][22][23]

한 가지 접근 방식은 장애 허용 시스템을 위해 펌웨어와 커널 지원을 사용하고, 필요한 경우 암호학 메커니즘과 같은 기능을 추가하여 악의적인 동작에 대한 보안 정책을 구축하며, 일부 책임을 컴파일러에 위임하는 것이다. 보안 정책 집행을 컴파일러 및 응용 프로그램 수준으로 위임하는 접근 방식을 종종 언어 기반 보안이라 한다.

현재 주류 운영체제에서 많은 중요한 보안 메커니즘이 부족하면 응용 프로그램 추상화 계층 수준에서 적절한 보안 정책을 구현하는 데 방해가 된다.[20] 사실 컴퓨터 보안에서 흔한 오해 중 하나는 커널 지원과 상관없이 응용 프로그램에서 어떤 보안 정책이든 구현할 수 있다는 것이다.[20]

Mars Research Group 개발자들에 따르면 격리 부족은 커널 보안을 약화시키는 주요 요인 중 하나이다.[24] 그들은 주로 리눅스 커널에서 보호를 위해 드라이버 격리 프레임워크를 제안한다.[25][26]

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

[편집]

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

대안적인 접근 방식은 언어 기반 보호를 사용하는 것이다. 언어 기반 시스템에서 커널은 신뢰할 수 있는 언어 컴파일러에 의해 생성된 코드만 실행하도록 허용한다. 언어는 프로그래머가 보안 요구 사항을 위반하는 작업을 수행하도록 지시하는 것이 불가능하게 설계될 수 있다.[19]

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

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

단점은 다음과 같다.

  • 더 긴 응용 프로그램 시작 시간. 응용 프로그램이 시작될 때 올바른 컴파일러로 컴파일되었는지 확인해야 하거나 소스 코드 또는 바이트코드로부터 재컴파일해야 할 수 있다.
  • 경직된 자료형 체계. 기존 시스템에서 응용 프로그램은 종종 자료형 안전하지 않은 작업을 수행한다. 이러한 작업은 언어 기반 보호 시스템에서 허용될 수 없으며, 이는 응용 프로그램이 다시 작성되어야 하거나 경우에 따라 성능이 저하될 수 있음을 의미한다.

언어 기반 보호가 있는 시스템의 예로는 JX와 마이크로소프트의 싱귤래러티가 있다.

프로세스 협력

[편집]

에츠허르 데이크스트라는 논리적 관점에서 원자적 락 및 바이너리 세마포어에서 작동하는 언락 연산이 프로세스 협력의 모든 기능을 표현하기에 충분한 기본 요소임을 증명했다.[28] 그럼에도 불구하고 이 접근 방식은 안전성과 효율성 측면에서 일반적으로 부족하다고 평가되며, 메시지 전달 방식이 더 유연하다.[29] 다른 여러 접근 방식(저수준 또는 고수준)도 사용 가능하며, 많은 현대 커널은 공유 메모리 및 원격 프로시저 호출과 같은 시스템에 대한 지원을 제공한다.

입출력 장치 관리

[편집]

입출력 장치가 다른 프로세스와 동일하게 병렬 협력 프로세스로 균일하게 처리되는 커널의 아이디어는 브린치 한센에 의해 처음 제안되고 구현되었다(1967년에도 비슷한 아이디어가 제안되었지만[30][31]). 한센의 설명에서 "공통" 프로세스는 내부 프로세스라고 불리고 입출력 장치는 외부 프로세스라고 불린다.[29]

물리적 메모리와 마찬가지로 응용 프로그램이 컨트롤러 포트와 레지스터에 직접 접근하도록 허용하면 컨트롤러가 오작동하거나 시스템이 충돌할 수 있다. 이로 인해 장치의 복잡성에 따라 일부 장치는 프로그래밍하기가 놀랍도록 복잡해지고 여러 개의 서로 다른 컨트롤러를 사용할 수 있다. 따라서 장치를 관리하기 위해 더 추상적인 인터페이스를 제공하는 것이 중요하다. 이 인터페이스는 일반적으로 장치 드라이버나 하드웨어 추상화 계층에 의해 수행된다. 응용 프로그램은 종종 이러한 장치에 대한 접근이 필요하다. 커널은 어떤 방식으로든 시스템을 쿼리하여 이러한 장치 목록을 유지해야 한다. 이는 바이오스나 다양한 시스템 버스(PCI/PCIE 또는 USB 등)를 통해 수행될 수 있다. 비디오 드라이버의 예를 들어, 응용 프로그램이 문자를 표시하는 것과 같은 장치 작업을 요청하면 커널은 이 요청을 현재 활성 상태인 비디오 드라이버로 보내야 한다. 그러면 비디오 드라이버가 이 요청을 수행해야 한다. 이것이 프로세스 간 통신(IPC)의 한 예이다.

커널 전반의 설계 접근 방식

[편집]

위에 나열된 작업과 기능은 설계와 구현이 서로 다른 여러 방식으로 제공될 수 있다.

메커니즘과 정책의 분리 원칙은 마이크로커널과 모놀리식 커널이라는 두 가지 주요 철학의 실질적인 차이점이다.[32][33] 여기서 메커니즘은 많은 서로 다른 정책의 구현을 허용하는 지원이며, 정책은 특정한 "작동 모드"이다. 예:

  • 메커니즘: 사용자 로그인 시도가 인증 서버로 라우팅됨
  • 정책: 인증 서버가 데이터베이스에 저장된 비밀번호와 대조되는 비밀번호를 요구함

메커니즘과 정책이 분리되어 있으므로 정책을 예를 들어 보안 토큰을 사용하도록 쉽게 변경할 수 있다.

최소한의 마이크로커널에는 몇 가지 매우 기본적인 정책만 포함되어 있으며,[33] 메커니즘은 커널 상단에서 실행되는 것(운영체제의 나머지 부분 및 다른 응용 프로그램)이 (메모리 관리, 고수준 프로세스 스케줄링, 파일 시스템 관리 등) 어떤 정책을 채택할지 결정하도록 허용한다.[6][29] 반면 모놀리식 커널은 많은 정책을 포함하는 경향이 있으며 따라서 나머지 시스템이 그것에 의존하도록 제한한다.

컴퓨터 과학자 브린치 한센은 메커니즘과 정책의 분리를 옹호했다.[6][29] 이러한 분리를 제대로 수행하지 못한 것은 기존 운영체제에서 실질적인 혁신이 부족한 주요 원인 중 하나이며,[6] 이는 컴퓨터 구조에서 흔한 문제이다.[34][35][36] 모놀리식 설계는 일반적인 상용 시스템에서 공통적으로 사용되는 보호를 위한 "커널 모드"/"사용자 모드" 아키텍처 접근 방식(기술적으로 계층적 보호 도메인이라 함)에 의해 유도된다.[37] 사실 보호가 필요한 모든 모듈은 따라서 커널에 포함되는 것이 바람직하다.[37] 모놀리식 설계와 "특권 모드" 사이의 이러한 연결은 메커니즘-정책 분리라는 핵심 문제로 다시 이어질 수 있다.[6] 사실 "특권 모드" 아키텍처 접근 방식은 보호 메커니즘을 보안 정책과 함께 융합시키는 반면, 주요 대안적 아키텍처 접근 방식인 기능 기반 주소 지정은 둘 사이를 명확하게 구분하여 자연스럽게 마이크로커널 설계로 이어진다.[6]

모놀리식 커널은 모든 코드를 동일한 주소 공간(커널 공간)에서 실행하는 반면, 마이크로커널은 코드베이스의 유지보수성과 모듈성을 개선하기 위해 대부분의 서비스를 사용자 공간에서 실행하려고 한다.[5] 대부분의 커널은 정확히 이러한 범주 중 하나에 들어맞지 않고 이 두 설계 사이에 위치한다. 이를 하이브리드 커널이라 한다. 나노커널이나 엑소커널과 같은 더 이색적인 설계도 가능하지만 운영 시스템에 거의 사용되지 않는다. 예를 들어 젠 하이퍼바이저는 엑소커널이다.

모놀리식 커널

[편집]
모놀리식 커널 다이어그램

모놀리식 커널에서 모든 OS 서비스는 커널의 일부이며 커널 모드에서 실행되므로 동일한 메모리 영역에 상주한다. 이 접근 방식은 풍부하고 강력한 하드웨어 접근을 제공한다. 유닉스 개발자 켄 톰프슨은 "내 생각에 모놀리식 커널을 구현하는 것이 더 쉽다"고 말했다.[38] 모놀리식 커널의 주요 단점은 시스템 구성 요소 간의 의존성(예: 장치 드라이버의 버그가 전체 시스템을 충돌시킬 수 있음)과 대규모 커널이 매우 유지보수하기 어려워질 수 있다는 사실이다. 톰프슨은 또한 "모놀리식 커널은 수정됨에 따라 급격히 엉망으로 변하기 쉽다"고 말했다.[38]

전통적으로 유닉스 계열 운영체제에서 사용되던 모놀리식 커널은 모든 운영체제 핵심 기능과 장치 드라이버를 포함한다. 모놀리식 커널은 커널 관련 모든 작업을 수행하는 데 필요한 모든 코드를 포함하는 하나의 단일 프로그램이다. 라이브러리에 넣을 수 없어 프로그램이 접근해야 하는 모든 부분은 드라이버, 스케줄러, 메모리 관리, 파일 시스템, 네트워크 스택을 포함하여 커널 공간에 있다. 응용 프로그램이 이러한 모든 서비스에 접근할 수 있도록 많은 시스템 호출이 제공된다. 모놀리식 커널은 처음에 필요하지 않을 수 있는 하위 시스템과 함께 로드되지만 일반적인 의미에서 더 관련성이 높더라도 하드웨어를 위해 특별히 설계된 것만큼 빠르거나 더 빠르게 조정될 수 있다.

리눅스 커널, FreeBSD 커널, IBM AIX 커널, HP-UX 커널, 오라클 솔라리스 커널과 같은 현대 모놀리식 커널(모두 유닉스 계열 운영체제 범주에 속함)은 모두 적재 가능 커널 모듈을 지원하여 런타임에 커널에 모듈을 로드할 수 있게 한다. 이를 통해 필요에 따라 커널 기능을 쉽게 확장할 수 있으며 커널 공간에서 실행되는 코드 양을 최소화하는 데 도움이 된다.

모놀리식 커널에서 대부분의 작업은 시스템 호출을 통해 수행된다. 이는 일반적으로 표 형식 구조로 유지되는 인터페이스로, 디스크 작업과 같은 커널 내의 하위 시스템에 접근한다. 본질적으로 호출은 프로그램 내에서 이루어지며 요청의 검증된 사본이 시스템 호출을 통해 전달된다. 따라서 이동 거리가 멀지 않다. 모놀리식 리눅스 커널은 모듈을 동적으로 로드하는 능력 때문뿐만 아니라 사용자 정의가 쉽기 때문에 극도로 작게 만들 수 있다. 사실 많은 유틸리티 및 기타 프로그램과 함께 플로피 디스크 한 장에 들어가면서도 완전히 기능하는 운영체제를 제공하는 버전도 존재한다(가장 인기 있는 것 중 하나는 muLinux이다). 커널을 소형화할 수 있는 이러한 능력은 임베디드 시스템에서 리눅스 사용을 급격히 성장시켰다.

이러한 유형의 커널은 운영체제의 핵심 기능과 런타임에 모듈을 로드할 수 있는 기능이 있는 장치 드라이버로 구성된다. 이들은 기본 하드웨어의 풍부하고 강력한 추상화를 제공한다. 이들은 일련의 간단한 하드웨어 추상화를 제공하며 서버라고 불리는 응용 프로그램을 사용하여 더 많은 기능을 제공한다. 이 특별한 접근 방식은 프로세스 관리, 병행성, 메모리 관리와 같은 운영체제 서비스를 슈퍼바이저 모드에서 실행되는 여러 모듈로 구현하기 위한 일련의 시스템 호출을 통해 하드웨어 위에 고수준 가상 인터페이스를 정의한다. 이 설계에는 몇 가지 결함과 제한 사항이 있다.

  • 커널에서 코딩하는 것은 어려울 수 있는데, 부분적으로는 공통 라이브러리(완벽한 기능을 갖춘 libc 등)를 사용할 수 없고 gdb와 같은 소스 수준 디버거를 사용해야 하기 때문이다. 컴퓨터 재부팅이 종종 필요하다. 이는 개발자에게 편의상의 문제만이 아니다. 디버깅이 어려울수록 코드가 더 "버그가 많아질" 가능성이 커진다.
  • 커널의 한 부분에 있는 버그는 강한 부작용을 갖는다. 커널의 모든 함수가 모든 권한을 가지고 있기 때문에 한 함수의 버그가 커널의 다른 완전히 무관한 부분이나 실행 중인 모든 프로그램의 데이터 구조를 손상시킬 수 있다.
  • 커널은 종종 매우 커지고 유지보수하기 어려워진다.
  • 이러한 작업을 서비스하는 모듈이 전체와 분리되어 있더라도 코드 통합은 밀접하고 올바르게 수행하기 어렵다.
  • 모듈이 동일한 주소 공간에서 실행되므로 버그가 전체 시스템을 다운시킬 수 있다.
마이크로커널 접근 방식에서 커널 자체는 서버 실행을 허용하는 기본적인 기능만 제공한다. 서버는 장치 드라이버, GUI 서버 등과 같은 이전 커널 기능을 대신하는 별도의 프로그램이다.

마이크로커널

[편집]

마이크로커널(μK 또는 uK라고도 약칭)은 시스템의 기능을 전통적인 "커널" 외부로 이동시켜 "최소한의" 커널을 통해 통신하는 일련의 "서버"로 만드는 운영체제 설계 접근 방식을 설명하는 용어이다. 이는 "시스템 공간"에 가능한 한 적게 남기고 "사용자 공간"에 가능한 한 많이 남기는 것을 목표로 한다. 특정 플랫폼이나 장치를 위해 설계된 마이크로커널은 작동하는 데 필요한 것만 가진다. 마이크로커널 접근 방식은 메모리 관리, 다중작업, 프로세스 간 통신과 같은 최소한의 OS 서비스를 구현하기 위한 일련의 기본 요소 또는 시스템 호출을 통해 하드웨어 위에 간단한 추상화를 정의하는 것으로 구성된다. 컴퓨터 망과 같이 일반적으로 커널이 제공하는 서비스를 포함한 다른 서비스는 서버라고 하는 사용자 공간 프로그램에서 구현된다. 마이크로커널은 모놀리식 커널보다 유지보수하기 쉽지만 많은 시스템 호출과 문맥 교환으로 인해 시스템이 느려질 수 있는데, 이는 일반적인 함수 호출보다 오버헤드가 더 많이 발생하기 때문이다.

IPC(프로세스 간 통신), 기본적인 스케줄러 또는 스케줄링 기본 요소, 기본 메모리 처리, 기본 입출력 기본 요소와 같이 특권 모드에 있어야 할 필요가 있는 부분만 커널 공간에 있다. 전체 스케줄러, 메모리 처리, 파일 시스템, 네트워크 스택 등 많은 중요한 부분이 이제 사용자 공간에서 실행된다. 마이크로커널은 모든 시스템 기능이 프로세서의 특수 "시스템" 모드에서 실행되는 하나의 정적 프로그램에 들어가는 전통적인 "모놀리식" 커널 설계에 대한 반작용으로 발명되었다. 마이크로커널에서는 일부(전부는 아닐 수 있음) 하드웨어에 접근하고, 메모리를 관리하고, 프로세스 간의 메시지 전달을 조정하는 등 가장 기본적인 작업만 이 수준에서 수행된다. 마이크로커널을 사용하는 시스템으로는 QNX와 GNU 허드가 있다. QNX와 GNU 허드의 경우 사용자 세션이 시스템 자체의 전체 스냅샷이거나 언급된 대로 "뷰"가 될 수 있다. 마이크로커널 아키텍처의 본질은 다음과 같은 장점을 보여준다.

  • 유지보수가 더 쉬움
  • 패치를 별도의 인스턴스에서 테스트한 다음 프로덕션 인스턴스를 인수하도록 교체할 수 있음
  • 빠른 개발 시간과 커널을 재부팅하지 않고도 새 소프트웨어를 테스트할 수 있음
  • 전반적으로 더 많은 지속성: 한 인스턴스가 오작동하면 오작동하는 서비스를 운영 중인 미러로 대체하는 것이 종종 가능함

대부분의 마이크로커널은 서버 간의 요청을 처리하기 위해 메시지 전달 시스템을 사용한다. 메시지 전달 시스템은 일반적으로 마이크로커널과 함께 포트 기반으로 작동한다. 예를 들어, 더 많은 메모리에 대한 요청이 전송되면 마이크로커널과 포트가 열리고 요청이 전송된다. 마이크로커널 내부에 들어가면 단계는 시스템 호출과 유사하다. 그 근거는 시스템 아키텍처에 모듈성을 가져와 디버그하거나 동적으로 수정하기 쉽고, 사용자의 요구에 맞게 사용자 정의할 수 있고, 성능이 더 높은 더 깔끔한 시스템을 만드는 것이었다. 마이크로커널은 GNU 허드, MINIX, MkLinux, QNX, 레독스 OS와 같은 운영체제의 일부이다.

마이크로커널은 자체적으로는 매우 작지만 필요한 모든 보조 코드와 결합하면 사실 모놀리식 커널보다 더 큰 경우가 많다. 모놀리식 커널 옹호자들은 또한 운영체제의 대부분이 하드웨어와 직접 상호 작용하지 않는 마이크로커널 시스템의 2단계 구조가 시스템 효율성 측면에서 적지 않은 비용을 발생시킨다고 지적한다. 이러한 유형의 커널은 일반적으로 메모리 주소 공간 정의, 프로세스 간 통신(IPC) 및 프로세스 관리와 같은 최소한의 서비스만 제공한다. 하드웨어 프로세스를 실행하는 것과 같은 다른 기능틀:Explain-wrap은 마이크로커널에 의해 직접 처리되지 않는다. 마이크로커널 지지자들은 모놀리식 커널이 커널의 오류가 전체 시스템을 충돌시킬 수 있다는 단점이 있다고 지적한다. 그러나 마이크로커널을 사용하면 커널 프로세스가 충돌하더라도 오류를 일으킨 서비스를 다시 시작하는 것만으로 시스템 전체의 충돌을 방지할 수 있다.

네트워킹과 같이 커널이 제공하는 다른 서비스는 서버라고 하는 사용자 공간 프로그램에서 구현된다. 서버를 사용하면 프로그램을 시작하고 중지하는 것만으로 운영체제를 수정할 수 있다. 예를 들어 네트워킹 지원이 없는 컴퓨터의 경우 네트워킹 서버를 시작하지 않는다. 다양한 응용 프로그램과 서버 간에 데이터를 이동하기 위해 커널 내부와 외부를 이동하는 작업은 모놀리식 커널에 비해 마이크로커널의 효율성을 떨어뜨리는 오버헤드를 만든다.

그러나 마이크로커널에는 단점이 존재한다. 일부는 다음과 같다.

  • 더 큰 실행 메모리 풋프린트
  • 인터페이스를 위한 소프트웨어가 더 많이 필요하므로 성능 손실 가능성이 있음
  • 메시지 전달 버그는 모놀리식 커널에서의 일회성 복사에 비해 더 긴 이동 경로를 거쳐야 하므로 수정하기 더 어려울 수 있음
  • 전반적인 프로세스 관리가 매우 복잡할 수 있음

마이크로커널의 단점은 매우 상황에 따라 다르다. 예를 들어, 소규모 단일 목적(및 중요한) 시스템에서는 실행해야 할 프로세스가 많지 않으면 프로세스 관리의 복잡성이 효과적으로 완화되므로 잘 작동한다.

마이크로커널은 운영체제의 나머지 부분을 사용자 모드에서 실행되는 프로그램으로 구현하고 동일한 변경되지 않은 커널 위에서 서로 다른 운영체제를 사용할 수 있게 한다. 또한 운영체제 간에 동적으로 전환하거나 둘 이상을 동시에 활성화하는 것도 가능하다.[29]

모놀리식 커널 vs. 마이크로커널

[편집]

컴퓨터 커널이 성장함에 따라 메모리 풋프린트와 함께 신뢰 컴퓨팅 기반의 크기와 취약성도 커진다. 이는 가상 메모리 시스템을 완성함으로써 어느 정도 완화되지만 모든 컴퓨터 구조가 가상 메모리 지원을 갖춘 것은 아니다.[f] 커널의 풋프린트를 줄이려면 수백만 줄의 코드인 커널의 부분들 간에 명확하지 않은 상호 의존성 때문에 매우 어려울 수 있는 불필요한 코드를 신중하게 제거하는 광범위한 편집을 수행해야 한다.

1990년대 초까지 모놀리식 커널 대 마이크로커널의 여러 단점으로 인해 모놀리식 커널은 거의 모든 운영체제 연구자들에 의해 구식으로 간주되었다. 결과적으로 리눅스를 마이크로커널이 아닌 모놀리식 커널로 설계한 것은 리누스 토르발스와 앤드루 타넨바움 사이의 유명한 논쟁 주제였다.[39] 타넨바움-토르발스 논쟁에서 제시된 주장에는 양측 모두 나름의 가치가 있다.

성능

[편집]

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

마이크로커널의 성능은 1980년대와 1990년대 초 모두 나빴다.[42][43] 이러한 마이크로커널의 성능을 경험적으로 측정한 연구들은 그러한 비효율성의 원인을 분석하지 않았다.[42] 이 데이터에 대한 설명은 "민속(folklore)"에 맡겨졌으며 그 원인이 "커널 모드"에서 "사용자 모드"로의 전환 빈도 증가, 프로세스 간 통신 빈도 증가, 문맥 교환 빈도 증가 때문이라고 가정했다.[42]

사실 1995년에 추측했듯이 마이크로커널의 성능이 낮은 이유는 (1) 전체 마이크로커널 접근 방식의 실제 비효율성, (2) 해당 마이크로커널에서 구현된 특정 개념, (3) 해당 개념의 특정 구현 때문일 수 있다. 따라서 효율적인 마이크로커널을 구축하는 해결책이 이전 시도들과 달리 올바른 구성 기술을 적용하는 것인지 연구할 필요가 있었다.[42]

반면에 모놀리식 커널 설계로 이어지는 계층적 보호 도메인 아키텍처[37]는 다른 보호 수준 간의 상호 작용이 있을 때마다(즉, 프로세스가 "사용자 모드"와 "슈퍼바이저 모드" 모두에서 데이터 구조를 조작해야 할 때) 상당한 성능 결함이 있는데, 이는 값에 의한 호출을 통한 메시지 복사를 필요로 하기 때문이다.[44]

하이브리드 커널 접근 방식은 모놀리식 커널의 속도와 더 간단한 설계와 마이크로커널의 모듈성 및 실행 안전성을 결합한다.

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

[편집]

하이브리드 커널은 현재까지 대부분의 마이크로소프트 윈도우 버전을 포함한 일부 상용 운영체제에 사용된다(윈도우 NT 3.1, 윈도우 NT 3.5, 윈도우 NT 3.51, 윈도우 NT 4.0, 윈도우 2000, 윈도우 XP, 윈도우 비스타, 윈도우 7, 윈도우 8, 윈도우 8.1, 윈도우 10, 윈도우 11). 애플의 macOS는 OSF/1의 Mach 커널(OSFMK 7.3)[45]과 FreeBSD의 모놀리식 커널 코드를 기반으로 하는 XNU라는 하이브리드 커널을 사용한다. 하이브리드 커널은 성능을 향상하기 위해 커널 공간에 추가 코드를 포함한다는 점을 제외하면 마이크로커널과 유사하다. 이 커널은 일부 개발자가 모놀리식 커널과 마이크로커널의 주요 장점을 수용하기 위해 구현한 절충안을 나타낸다. 이러한 유형의 커널은 모놀리식 커널의 일부 속성을 가진 마이크로커널의 확장이다. 모놀리식 커널과 달리 이러한 유형의 커널은 독자적으로 런타임에 모듈을 로드할 수 없다. 이는 전통적인 마이크로커널의 성능 오버헤드를 줄이기 위해 커널 공간에서 일부 서비스(예: 네트워크 스택 또는 파일 시스템)를 실행하지만 커널 코드(장치 드라이버 등)는 여전히 사용자 공간에서 서버로 실행함을 의미한다.

많은 전통적인 모놀리식 커널이 적재 가능 커널 모듈을 지원한다. 가장 잘 알려진 커널은 리눅스 커널이다. 모듈형 커널은 본질적으로 코어 커널 바이너리에 빌드되거나 필요할 때 메모리로 로드되는 바이너리에 그 일부를 가질 수 있다. 코드 오염된 모듈은 실행 중인 커널을 불안정하게 만들 가능성이 있다. 대조적으로 마이크로커널을 위한 드라이버를 완전히 분리된 메모리 공간에 작성하고 "실시간"으로 전환하기 전에 테스트할 수 있다. 커널 모듈이 로드되면 필요한 것을 추가하여 모놀리식 부분의 메모리 공간에 접근하므로 오염 가능성이 있는 문을 연다. 모듈형(또는) 하이브리드 커널의 몇 가지 장점은 다음과 같다.

  • 모듈 내부에서 작동할 수 있는 드라이버에 대한 더 빠른 개발 시간. 테스트를 위한 재부팅이 필요 없음(커널이 불안정해지지 않는 경우).
  • 새로운 드라이버나 하위 시스템 등을 위해 전체 커널을 재컴파일하는 시간을 소비하는 대신 온디맨드 기능 사용.
  • 타사 기술의 더 빠른 통합(개발과 관련이 있지만 그 자체로 관련됨).

모듈은 일반적으로 일종의 모듈 인터페이스를 사용하여 커널과 통신한다. 인터페이스는 일반화되어 있으므로(주어진 운영체제에 따라 다르지만) 항상 모듈을 사용할 수 있는 것은 아니다. 종종 장치 드라이버는 모듈 인터페이스가 제공하는 것보다 더 많은 유연성이 필요할 수 있다. 본질적으로 이는 두 개의 시스템 호출이며, 모놀리식 커널에서 한 번만 수행하면 되는 안전성 검사를 이제 두 번 수행해야 하는 경우가 많다. 모듈형 접근 방식의 단점은 다음과 같다.

  • 통과해야 할 인터페이스가 많아지면 버그 증가 가능성이 존재함(더 많은 보안 구멍을 의미).
  • 기호 차이와 같은 문제를 처리할 때 관리자가 모듈 유지보수를 혼동할 수 있음.

나노커널

[편집]

나노커널은 커널 메모리 요구 사항을 전통적인 마이크로커널보다 더 작게 만들기 위해 인터럽트 컨트롤러나 타이머와 같은 가장 기본적인 것조차 장치 드라이버에 위임하는 방식이다.[46]

엑소커널

[편집]

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

엑소커널 자체는 매우 작다. 그럼에도 불구하고 이들은 응용 프로그램 개발자에게 전통적인 운영체제의 기능을 제공하는 라이브러리 운영체제(참조: 유니커널)를 동반한다. 엑소커널 기반 시스템의 주요 장점은 고수준 사용자 인터페이스 개발을 위한 API와 실시간 제어를 위한 API 등 각각 다른 API를 내보내는 여러 라이브러리 운영체제를 통합할 수 있다는 것이다.

멀티커널

[편집]

멀티커널 운영체제는 분산 시스템처럼 멀티 코어 머신을 독립적인 코어들의 네트워크로 처리한다. 공유 메모리를 가정하지 않고 대신 프로세스 간 통신을 메시지 전달로 구현한다.[47][48] Barrelfish는 멀티커널로 설명된 최초의 운영체제였다.

커널 개발의 역사

[편집]

초기 운영체제 커널

[편집]

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

1969년 RC 4000 Multiprogramming System은 "다양한 목적을 위한 운영체제를 질서 정연하게 구축할 수 있는" 작은 핵이라는 시스템 설계 철학을 도입했으며,[50] 이를 마이크로커널 접근 방식이라 부르게 되었다.

시분할 운영체제

[편집]

유닉스 이전 10년 동안 컴퓨터는 성능이 엄청나게 성장하여 컴퓨터 운영자가 기계의 남는 시간에 사람들이 기계에 접근할 수 있는 새로운 방법을 찾고 있었다. 이 시대의 주요 발전 중 하나는 시분할 시스템이었으며, 이를 통해 많은 사용자가 마치 각자가 더 느린 자신만의 기계에 연결된 것처럼 보이는 속도로 컴퓨터 시간을 조금씩 얻을 수 있었다.[51]

시분할 시스템의 개발은 여러 문제로 이어졌다. 하나는 시스템을 개발 중인 대학교의 사용자들이 중앙 처리 장치 시간을 더 얻기 위해 시스템을 해킹하기를 원했다는 것이다. 이러한 이유로 컴퓨터 보안과 접근 제어는 1965년 멀틱스 프로젝트의 주요 초점이 되었다.[52] 또 다른 지속적인 문제는 컴퓨팅 자원을 제대로 처리하는 것이었다. 사용자는 컴퓨터 자원을 실제로 사용하는 대신 터미널을 쳐다보며 무엇을 입력할지 생각하는 데 대부분의 시간을 보냈으며, 시분할 시스템은 이러한 기간 동안 활성 사용자에게 CPU 시간을 주어야 했다. 마지막으로 시스템은 일반적으로 여러 계층 깊이의 메모리 계층 구조를 제공했으며, 이 값비싼 자원을 분할하는 것은 가상 메모리 시스템의 주요 발전으로 이어졌다.

아미가

[편집]

코모도어 인터내셔널의 아미가는 1985년에 출시되었으며 발전된 커널 아키텍처를 특징으로 하는 첫 번째(가장 성공적인) 가정용 컴퓨터 중 하나였다. 아미가OS 커널의 실행 구성 요소인 exec.library는 마이크로커널 메시지 전달 설계를 사용하지만, graphics.library와 같이 하드웨어에 직접 접근하는 다른 커널 구성 요소도 있다. 메모리 보호는 없으며 커널은 거의 항상 사용자 모드에서 실행된다. 특별한 작업만 커널 모드에서 실행되며, 사용자 모드 응용 프로그램은 운영체제에 커널 모드에서 코드를 실행하도록 요청할 수 있다.

유닉스

[편집]
유닉스 계열 시스템을 위한 선조/후손 가족 관계 다이어그램

유닉스의 설계 단계에서 프로그래머는 컴퓨테이션의 목적이 데이터 트랜스포메이션이라고 믿었기 때문에 모든 고수준 장치를 파일로 모델링하기로 결정했다.[53]

예를 들어, 프린터는 알려진 위치의 "파일"로 표시되었다. 데이터가 파일에 복사되면 인쇄되었다. 유사한 기능을 제공하기 위한 다른 시스템들은 더 낮은 수준에서 장치를 가상화하는 경향이 있었다. 즉, 장치와 파일 모두 특정 저수준 개념의 인스턴스였다. 파일 수준에서 시스템을 가상화하면 사용자가 기존 파일 관리자 유틸리티와 개념을 사용하여 전체 시스템을 조작할 수 있어 작업이 획기적으로 단순화되었다. 동일한 패러다임의 확장으로서 유닉스는 프로그래머가 파이프 개념을 사용하여 작은 프로그램 시리즈로 파일을 조작할 수 있도록 했으며, 이를 통해 사용자는 단일 목적 도구 체인을 통해 파일을 전달하면서 단계별로 작업을 완료할 수 있었다. 최종 결과는 동일했지만 이런 방식으로 작은 프로그램을 사용하는 것은 개발 및 사용의 용이성뿐만 아니라 유연성을 획기적으로 높였으며, 사용자가 체인에 프로그램을 추가하거나 제거하여 워크플로우를 수정할 수 있게 했다.

유닉스 모델에서 운영체제는 두 부분으로 구성된다. 첫째, 대부분의 작업을 주도하는 방대한 유틸리티 프로그램 모음; 둘째, 프로그램을 실행하는 커널이다.[53] 유닉스에서 프로그래밍 관점으로 볼 때 둘 사이의 차이는 상당히 미미하다. 커널은 시스템의 나머지 부분을 구성하는 작은 유틸리티 프로그램들을 위한 프로그램 로더 및 관리자로서, 그리고 이러한 프로그램을 위해 락 및 입출력 서비스를 제공하기 위해 슈퍼바이저 모드에서 실행되는 프로그램이다.[g] 그 외에 커널은 사용자 공간에 전혀 개입하지 않았다.

수년에 걸쳐 컴퓨팅 모델이 변경되었고 유닉스의 모든 것은 파일이다라는 처리 방식이나 바이트 스트림은 이전처럼 보편적으로 적용 가능하지 않게 되었다. 단말기는 인쇄하거나 읽는 파일이나 바이트 스트림으로 처리될 수 있지만 그래픽 사용자 인터페이스는 그렇지 않은 것 같았다. 네트워킹은 또 다른 문제를 제기했다. 네트워크 통신을 파일 접근과 비교할 수 있더라도 저수준 패킷 지향 아키텍처는 전체 파일이 아니라 별개의 데이터 덩어리를 처리했다. 컴퓨터의 성능이 커짐에 따라 유닉스는 코드들로 점점 더 복잡해졌다. 유닉스 커널의 모듈성은 광범위하게 확장 가능하기 때문이기도 하다.[54] 70년대와 80년대에 커널이 100,000 라인의 코드를 가졌을 수 있지만, GNU와 같은 현대 유닉스 후계자의 리눅스와 같은 커널은 4,100만 줄 이상을 가지고 있다.[55]

현대 유닉스 파생물은 일반적으로 모듈 로딩 모놀리식 커널을 기반으로 한다. GNU의 많은 리눅스 배포판에 있는 리눅스 커널, IBM AIX, FreeBSD, DragonFly BSD, OpenBSD, NetBSD, macOS와 같은 BSD 변형 커널이 그 예이다. 이러한 대안 외에도 아마추어 개발자들은 스스로 작성한 취미용 커널들로 가득 찬 활발한 운영체제 개발 커뮤니티를 유지하고 있으며, 이 커널들은 대부분 리눅스, FreeBSD, DragonflyBSD, OpenBSD, NetBSD 커널과 많은 기능을 공유하거나 호환된다.[56]

클래식 맥 OS 및 MacOS

[편집]

애플은 1984년 자사의 개인용 컴퓨터인 매킨토시와 함께 클래식 맥 OS를 처음 출시했다. 애플은 맥 OS 8.6에서 나노커널 설계로 이동했다. 이와 대조적으로 현대의 macOS(원래 명칭 Mac OS X)는 4.3BSD 커널과 Mach 커널을 결합하여 생성된 XNU라는 하이브리드 커널을 사용하는 다윈을 기반으로 한다.[57]

마이크로소프트 윈도우

[편집]

마이크로소프트 윈도우는 1985년 MS-DOS의 애드온으로 처음 출시되었다. 다른 운영체제에 대한 의존성 때문에 윈도우 95 이전의 초기 윈도우 릴리스는 운영 환경으로 간주되었다. 이 제품 라인은 1980년대와 1990년대에 걸쳐 진화했으며, 윈도우 9x 시리즈는 32비트 주소 지정과 선점형 다중작업을 추가했지만 2000년 윈도우 미 출시와 함께 끝났다.

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

윈도우 NT 아키텍처의 커널은 클라이언트/서버 계층형 하위 시스템 모델과 함께 윈도우 관리자 및 IPC 관리자와 같은 작업을 커널 자체가 포함하고 있기 때문에 하이브리드 커널로 간주된다.[58] 윈도우 NT 커널은 Mach 마이크로커널의 영향을 받았지만 순수 마이크로커널의 모든 기준을 충족하지 않으므로 수정된 마이크로커널로 설계되었다.

IBM 슈퍼바이저

[편집]

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

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

CP-40 및 CP-67에서 IBM은 슈퍼바이저 상태를 하드웨어로부터 더 추상화하여 완전 가상화를 가능하게 하는 하이퍼바이저를 탄생시켰는데, 이는 같은 기계에서 여러 운영체제를 서로 완전히 독립적으로 실행할 수 있는 능력이다.

1970년대에 IBM은 System/370을 위해 CP/CMS를 Virtual Machine Facility/370(VM/370)이라는 이름으로 업데이트했다. 따라서 첫 번째 그러한 시스템을 가상 머신 또는 VM이라 불렀다.

마이크로커널의 개발

[편집]

카네기 멜런 대학교의 리처드 라시드가 개발한 Mach가 가장 잘 알려진 범용 마이크로커널이지만, 더 구체적인 목표를 가진 다른 마이크로커널들이 개발되었다. L4 마이크로커널 계열(주로 L3 및 L4 커널)은 마이크로커널이 반드시 느린 것은 아님을 증명하기 위해 만들어졌다.[59] Fiasco 및 Pistachio와 같은 새로운 구현은 별도의 주소 공간에서 다른 L4 프로세스 옆에서 리눅스를 실행할 수 있다.[60][61]

또한 QNX는 주로 임베디드 시스템에서 사용되는 마이크로커널이며,[62] 오픈 소스 소프트웨어인 MINIX는 원래 교육용으로 만들어졌으나 현재는 매우 신뢰할 수 있는 및 자가 치유 마이크로커널 OS가 되는 데 중점을 두고 있다.

같이 보기

[편집]

각주

[편집]
  1. ↑ 컴퓨터인터넷IT용어대사전-핵심
  2. 1 2 “Kernel”. 《Linfo》. Bellevue Linux Users Group. 2006년 12월 8일에 원본 문서에서 보존된 문서. 2016년 9월 15일에 확인함.
  3. ↑ Randal E. Bryant; David R. O'Hallaron (2016). 《Computer Systems: A Programmer's Perspective》 Thi판. Pearson. 17쪽. ISBN 978-0-13-409266-9.
  4. ↑ 참조: 데몬 (컴퓨팅)
  5. 1 2 Roch 2004
  6. 1 2 3 4 5 6 7 Wulf 1974 pp.337–345
  7. 1 2 Silberschatz 1991
  8. ↑ Tanenbaum, Andrew S. (2008). 《Modern Operating Systems》 3판. Prentice Hall. 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 . . .
  9. ↑ 〈Miscellaneous Operations〉 (PDF). 《GE-625/635 Programming Reference Manual》 (PDF). Rev. April 1968. 제너럴 일렉트릭. July 1964. 132쪽. CPB-1004F. 2026년 7월 7일에 확인함.
  10. ↑ 〈Supervisor Call〉 (PDF) Eigh판. 《IBM System/360 Principles of Operation》 (PDF). Systems Reference Library. IBM. September 1968. 74쪽. A22-6821-7. 2026년 7월 7일에 확인함.
  11. ↑ 〈2.16 Unimplemented Operations〉 (PDF). 《DECsystem-10 - DECSYSTEM-20 - Processor Reference Manual - AA-H391A-TK, AM-4391A-T1》 (PDF). June 1982. 2–123–2–127쪽. AD-H391A. 2026년 7월 7일에 확인함.
  12. ↑ Denning 1976
  13. ↑ Swift 2005, p.29 quote: "isolation, resource control, decision verification (checking), and error recovery."
  14. ↑ Schroeder 72
  15. 1 2 Linden 76
  16. ↑ 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.
  17. ↑ Silberschatz & Galvin, Operating System Concepts, 4th ed, pp. 445 & 446
  18. ↑ 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.
  19. 1 2 Schneider, Fred B.; Morrissett, Greg; Harper, Robert. “A Language-Based Approach to Security” (PDF). 2018년 12월 22일에 원본 문서 (PDF)에서 보존된 문서.
  20. 1 2 3 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》. 303–314쪽. 2007년 6월 21일에 원본 문서에서 보존된 문서.
  21. ↑ 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》. 133–140쪽. doi:10.1145/504450.504477. ISBN 978-1-4503-7339-5. S2CID 10027108.
  22. ↑ Anderson, J. (October 1972). Computer Security Technology Planning Study (PDF) (보고서) II. Air Force Electronic Systems Division. ESD-TR-73-51, Vol. II. 2011년 7월 21일에 원본 문서 (PDF)에서 보존된 문서.
  23. ↑ Jerry H. Saltzer; Mike D. Schroeder (September 1975). “The protection of information in computer systems”. 《Proceedings of the IEEE》 63 (9): 1278–1308. Bibcode:1975IEEEP..63.1278S. doi:10.1109/PROC.1975.9939. S2CID 269166. 2021년 3월 8일에 원본 문서에서 보존된 문서. 2007년 7월 15일에 확인함.
  24. ↑ “Fine-grained kernel isolation” (영어). 《mars-research.github.io》. 2022년 9월 15일에 확인함.
  25. ↑ Fetzer, Mary. “Automatic device driver isolation protects against bugs in operating systems” (영어). 《펜실베이니아 주립 대학교 via techxplore.com》. 2022년 9월 15일에 확인함.
  26. ↑ Huang, Yongzhe; Narayanan, Vikram; Detweiler, David; Huang, Kaiming; Tan, Gang; Jaeger, Trent; Burtsev, Anton (2022). “KSplit: Automating Device Driver Isolation” (PDF). 2023년 12월 20일에 확인함.
  27. ↑ 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.
  28. ↑ Dijkstra, E. W. (September 1965). 〈Co-operating sequential processes〉 (PDF). F. Genuys (편집). 《Programming languages: NATO Advanced Study Institute: lectures given at a three weeks Summer School held in Villard-le-Lans, 1966》. Academic Press Inc.. Math. Dep., Technological U., Eindhoven. 43–112쪽.
  29. 1 2 3 4 5 Brinch Hansen 70 pp.238–241
  30. ↑ 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.
  31. ↑ Huxtable, D. H. R.; Warwick, M. T. (1967). 〈Dynamic Supervisors - their design and construction〉. 《Proceedings of the ACM symposium on Operating System Principles - SOSP '67》. 11.1–11.17쪽. doi:10.1145/800001.811675. ISBN 978-1-4503-7370-8. S2CID 17709902.
  32. ↑ Baiardi 1988
  33. 1 2 Levin 75
  34. ↑ Denning 1980
  35. ↑ 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》. 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.
  36. ↑ Levy 84, p.1 quote: "Although the complexity of computer applications increases yearly, the underlying hardware architecture for applications has remained unchanged for decades."
  37. 1 2 3 Levy 84, p.1 quote: "기존의 아키텍처들은 단일 특권 동작 모드를 지원한다. 이러한 구조는 모놀리식 설계를 초래하는데, 보호가 필요한 모든 모듈은 단일 운영체제 커널의 일부여야만 하기 때문이다. 대신, 임의의 모듈이 보호된 도메인 내에서 실행될 수 있다면, 시스템은 임의의 사용자가 확장할 수 있는 독립적인 모듈들의 집합으로 구축될 수 있을 것이다."
  38. 1 2 “Open Sources: Voices from the Open Source Revolution”. 《1-56592-582-3》. 1999년 3월 29일. 2020년 2월 1일에 원본 문서에서 보존된 문서. 2019년 3월 24일에 확인함.
  39. ↑ 토르발스와 타넨바움 사이의 논쟁 기록은 dina.dk 보관됨 2012-10-03 - 웨이백 머신, groups.google.com 보관됨 2013-05-26 - 웨이백 머신, oreilly.com 보관됨 2014-09-21 - 웨이백 머신 및 앤드루 타넨바움의 웹사이트 보관됨 2015-08-05 - 웨이백 머신에서 찾을 수 있다.
  40. 1 2 Matthew Russell. “What Is Darwin (and How It Powers Mac OS X)”. 오라일리 미디어. 2007년 12월 8일에 원본 문서에서 보존된 문서. 2008년 12월 9일에 확인함. 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.
  41. ↑ “Operating Systems/Kernel_Models - Wikiversity”. 《en.wikiversity.org》. 2014년 12월 18일에 원본 문서에서 보존된 문서. 2014년 12월 18일에 확인함.
  42. 1 2 3 4 Liedtke 95
  43. ↑ Härtig 97
  44. ↑ Hansen 73, section 7.3 p.233 "interactions between different levels of protection require transmission of messages by value"
  45. ↑ Magee, Jim. 《WWDC 2000 Session 106 – Mac OS X: Kernel》. 14 분. 2022년 10월 8일에 원본 문서에서 보존된 문서. 2022년 7월 5일에 확인함.
  46. ↑ “KeyKOS Nanokernel Architecture”. 2011년 6월 21일에 원본 문서에서 보존된 문서.
  47. ↑ Baumann, Andrew; Barham, Paul; Dagand, Pierre-Evariste; Harris, Tim; Isaacs, Rebecca; Peter, Simon; Roscoe, Timothy; Schüpbach, Adrian; Singhania, Akhilesh (2009). 《The Multikernel: a new OS architecture for scalable multicore systems》 (PDF). 22nd Symposium on Operating Systems Principles.
  48. ↑ “The Barrelfish operating system”.
  49. ↑ Ball: Embedded Microprocessor Designs, p. 129
  50. ↑ Hansen 2001 (os), pp.17–18
  51. ↑ “BSTJ version of C.ACM Unix paper”. 《bell-labs.com》. 2005년 12월 30일에 원본 문서에서 보존된 문서. 2006년 8월 17일에 확인함.
  52. ↑ Corbató, F. J.; Vissotsky, V. A. 《Introduction and Overview of the Multics System》. 1965 Fall Joint Computer Conference. 2011년 7월 9일에 원본 문서에서 보존된 문서.
  53. 1 2 “The Single Unix Specification”. 오픈 그룹. 2016년 10월 4일에 원본 문서에서 보존된 문서. 2016년 9월 29일에 확인함.
  54. ↑ “Unix's Revenge”. 《asymco.com》. 2010년 9월 29일. 2010년 11월 9일에 원본 문서에서 보존된 문서. 2010년 10월 2일에 확인함.
  55. ↑ Wheeler, David A. (2004년 10월 12일). “Linux Kernel 2.6: It's Worth More!”.
  56. ↑ 이 커뮤니티는 주로 Bona Fide OS Development 보관됨 2022-01-17 - 웨이백 머신, The Mega-Tokyo Message Board 보관됨 2022-01-25 - 웨이백 머신 및 기타 운영체제 애호가 웹사이트에서 모인다.
  57. ↑ Singh, Amit (December 2003). “XNU: The Kernel”. 2011년 8월 12일에 원본 문서에서 보존된 문서.
  58. ↑ “Windows - Official Site for Microsoft Windows 10 Home & Pro OS, laptops, PCs, tablets & more”. 《windows.com》. 2011년 8월 20일에 원본 문서에서 보존된 문서. 2019년 3월 24일에 확인함.
  59. ↑ “The L4 microkernel family - Overview”. 《os.inf.tu-dresden.de》. 2006년 8월 21일에 원본 문서에서 보존된 문서. 2006년 8월 11일에 확인함.
  60. ↑ “The Fiasco microkernel - Overview”. 《os.inf.tu-dresden.de》. 2006년 6월 16일에 원본 문서에서 보존된 문서. 2006년 7월 10일에 확인함.
  61. ↑ Zoller (inaktiv), Heinz (2013년 12월 7일). “L4Ka - L4Ka Project”. 《www.l4ka.org》. 2001년 4월 19일에 원본 문서에서 보존된 문서. 2019년 3월 24일에 확인함.
  62. ↑ “QNX Operating Systems”. 《blackberry.qnx.com》. 2019년 3월 24일에 원본 문서에서 보존된 문서. 2019년 3월 24일에 확인함.
내용주
  1. ↑ 컴퓨터 구조에 따라 다를 수 있음
  2. ↑ Derail (DRL)도 있지만 역할이 제한적임.
  3. ↑ 예: 제너럴 일렉트릭의 GE-600 시리즈에 있는 마스터 모드 엔트리[9] (MME),[b] IBM 시스템/360의 슈퍼바이저 호출[10] (SVC)
  4. ↑ 예: DEC PDP-10에서 구현되지 않은 사용자 작업[11] (UUO)
  5. ↑ 일부 아키텍처는 인터럽트를 생성하는 데 전용되는 명령어[c] 또는 명령어 블록[d]을 사용한다. 일부 운영체제는 인터럽트를 재사용한다. 예: VM은 Diagnose 명령어로부터의 권한 있는 명령어 인터럽트를 사용한다.
  6. ↑ 가상 주소 지정은 가장 일반적으로 내장된 메모리 관리 장치를 통해 달성된다.
  7. ↑ 가장 높은 권한 수준은 슈퍼바이저 모드, 커널 모드, CPL0, DPL0, 링 0 등 다양한 아키텍처를 통해 다양한 이름을 가진다. 자세한 내용은 보호 링을 참조.

외부 링크

[편집]
원본 주소 "https://ko.wikipedia.org/w/index.php?title=커널_(컴퓨팅)&oldid=42800748"