[go: up one dir, main page]

KR20070005917A - 운영체제 - Google Patents

운영체제 Download PDF

Info

Publication number
KR20070005917A
KR20070005917A KR1020067008560A KR20067008560A KR20070005917A KR 20070005917 A KR20070005917 A KR 20070005917A KR 1020067008560 A KR1020067008560 A KR 1020067008560A KR 20067008560 A KR20067008560 A KR 20067008560A KR 20070005917 A KR20070005917 A KR 20070005917A
Authority
KR
South Korea
Prior art keywords
operating system
kernel
nanokernel
memory
context
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
KR1020067008560A
Other languages
English (en)
Inventor
에리크 레스쿠에트
블라디미르 그루즈데브
Original Assignee
쟈루나 에스에이
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 쟈루나 에스에이 filed Critical 쟈루나 에스에이
Publication of KR20070005917A publication Critical patent/KR20070005917A/ko
Withdrawn legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/48Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806Task transfer initiation or dispatching
    • G06F9/4843Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44Arrangements for executing specific programs
    • G06F9/455Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533Hypervisors; Virtual machine monitors
    • G06F9/4555Para-virtualisation, i.e. guest operating system has to be modified
    • BPERFORMING OPERATIONS; TRANSPORTING
    • B82NANOTECHNOLOGY
    • B82YSPECIFIC USES OR APPLICATIONS OF NANOSTRUCTURES; MEASUREMENT OR ANALYSIS OF NANOSTRUCTURES; MANUFACTURE OR TREATMENT OF NANOSTRUCTURES
    • B82Y10/00Nanotechnology for information processing, storage or transmission, e.g. quantum computing or single electron logic

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

복수의 다른 운영체제 프로그램을 인텔 또는 유사한 복합 명령 설정 컴퓨터 구조인 같은 컴퓨터에서 동시에 수행할 수 있게 하는 방법으로서, 상대적으로 높은 우선 순위(C5와 같은 실시간 운영체제)를 가지는 제1운영체제를 선택하는 단계, 상대적으로 낮은 우선 순위(리눅스와 같은 범용 운영체제)를 가지는 부수적 운영체제를 적어도 하나 이상 선택하는 단계, 예정된 조건 하에서 운영체제 사이를 교환하여 수행되도록 정해진 공통 프로그램(나노커널과 유사한 하드웨어 자원 디스패처)를 제공하는 단계, 제1운영체제와 부수적 운영체제가 공통 프로그램에 의하여 제어될 수 있도록 조절하는 단계로 구성되는 운영체제.
운영체제

Description

운영체제{Operating Systems}
본 발명은 운영체제에 관한 것이다. 보다 구체적으로는 본 발명은 복수의 운영체제가 동시에 수행되도록 하기 위한 시스템, 방법, 컴퓨터 프로그램에 관한 발명이다.
일부 컴퓨터 프로그램에서는 프로그램 단계들이 정해진 시간 내에 혹은 정해진 시각에 실행되는 것이 매우 중요하다. 그러한 프로그램의 예로서 휴대전화, 사설 전화스위칭기(PBXs), 휴대전화 기지국을 제어하는 프로그램들을 들 수 있다. 전형적으로는 이 프로그램들이 외부 이벤트나 상태 변화에 일관된 방식으로, 이벤트가 일어난 그 시각에 또는 그로부터 일정한 시간 내에 반응하여야만 한다. 이를 가리켜 "실시간"으로 작동한다고 일컫는다.
그러나, 다른 수많은 프로그램의 경우에는 프로그램을 실행하는데 드는 시간이 그리 중요하지 않다. 이는 대부분의 컴퓨터 프로그램에 해당되는데, 스프레드시트, 문서 편집기, 급여 관리, 그리고 일반적인 보고·분석용 프로그램이 이에 속한다. 한편 그러한 프로그램 실행에 걸린 정확한 시간은 중요하지 않을지라도, 대부분의 경우 사용자는 가능한 한 더 빠른 실행 속도를 선호한다.
응용 프로그램(applications program)은 그가 실행되는 컴퓨터 내에서 그 컴퓨터와 운영체제를 통하여 상호작용한다. 운영체제의 응용 프로그램용 인터페이스(API, applications programming interface)를 사용함으로써 이 응용 프로그램을 이동 가능한 형식으로 쓸 수 있으며, 그에 따라 서로 다른 하드웨어 자원을 갖춘 다양한 컴퓨터상에서 실행될 수 있게 된다. 게다가 리눅스나 윈도우즈와 같은 흔한 운영체제는 다중 처리(multi-tasking)를 지원한다. 즉 여러 프로그램들이 동시에 작동하게 하여 준다. 이렇게 하기 위하여서 운영체제는 스케줄링 기능을 제공한다. 달리 말하자면, 운영체제는 컴퓨터 자원의 사용량을 다른 프로그램들 사이에서 나눠주고, 스케줄링 알고리즘에 따라 각각의 프로그램들에게 시간을 배분한다. 이러한 종류의 운영체제는 아주 널리 쓰이지만, 이들은 실시간 응용 프로그램을 실행하는데 필요한 지원 기능이 마련되어 있지 않기 때문에 수많은 제어나 통신 분야의 작업에는 적합하지 않다.
따라서 그러한 작업을 위하여 실시간 운영체제가 개발되었다. 한 예로써 ChorusOS(Chorus로도 알려졌다)와 그 파생 체제들을 들 수 있다. Chorus는 http://www.experimentalstuff.com/Technologies/ChorusOS/index.html과 Jaluna社 http://www.jaluna.com으로부터 얻을 수 있는 공개 소스 소프트웨어이다.
Chorus는 2001년 8월자 Sun Technical Report, 222쪽 Francois Armand저 "ChorusOS Features and Architecture Overview"에 기술되고 있는데, 이는 http://www.jaluna.com/developer/papers/COSDESPERF.pdf에서 얻을 수 있다.
이들 운영체제는 다른 종류의 프로그램을 수행하는데 쓰일 수 있다. 그러나 사용자가 윈도우즈나 리눅스와 같은 범용 운영체제용으로 작성된 방대한 양의 "기존 사용" 프로그램("legacy" program)들에 대하여 실시간 운영체제에서도 수행가능하도록 고쳐 쓸 필요 없이 실행할 수 있기를 바라는 것은 이해할 수 있는 일이다.
"이중 부팅("dual boot")" 운영체제를 마련하여 사용자가 운영체제를 택일하여 운용하는 것도 가능하지만, "기존 사용" 프로그램을 실시간 프로그램과 동시에 실행하는 것이 바람직한 경우도 많이 있다. 예를 들어 통신망 기반 장비(telecommunications network infrastructure equipment), 제3세대 휴대전화와 다른 첨단 전화기, 첨단 전자 게임기 등은 실시간 응용 프로그램(예를 들어 게임용 그래픽)과 비실시간 응용 프로그램(게임 내려받기)이 모두 필요할 수 있다.
미국 특허 5903752호와 5721922호에서는 실시간 다중 처리 커널(multi-tasking kernel)을 비실시간 운영체제(윈도우즈와 같은)의 인터럽트 처리 환경에 제공함으로써 실시간 환경을 비실시간 운영체제에 도입하려는 시도를 하였다.
널리 사용된 한 가지 방식은 "에뮬레이션(emulation)"이다. 전형적인 에뮬레이터(emulator) 프로그램은 실시간 운영체제에서 실행되도록 작성되고, 범용 운영체제에서 작동하도록 짜여진 다른 프로그램의 각 명령을 해석한 뒤 그에 대응하는 명령들을 실시간 운영체제하에서 수행한다. 그러나 한 명령이 언제나 다수의 명령으로 대체되기 때문에 에뮬레이션은 컴퓨터에 큰 부담을 주고, 수행 속도를 떨어뜨린다. 가상 머신(예를 들어 JavaTM 가상 머신)의 제공에 기반하는 접근에서도 비슷한 문제가 일어난다. 가상 머신을 장착한 예로서 유럽 특허 1059582호와 미국 특허 5499379 및 4764864호를 들 수 있다.
비슷한 또 기술로서 미국 특허 5995745호(Yodaiken)가 있다. Yodaiken은 다중 처리 실시간 운영체제가 범용 운영체제를 수행 작업(task)으로서 실행하고 실시간 작업 수행의 필요에 따라 접수(pre-empt)하는 운영체제를 기술한 바 있다.
또 다른 방식은 실시간 운영체제를 범용 운영체제의 한 모듈로서 운용하는 것으로, 예를 들면 유럽 특허 0360135호와 Electronics誌 1990년 9월 62쪽 기사 "Merging real-tiem processing and UNIX V"(Gosch)에 기재되어있다. 이 경우에는 범용 운영체제와 관련된 하드웨어 인터럽트가 실시간 운영체제를 접수하지 못하도록 선택적으로 하드웨어 인터럽트를 금지(mask)한다.
또 방식은 http://opersys.com/ftp/pub/Adeos/adeos.pdf의 백서에 기술된 ADEOS(Adaptive Domain Environment for Operating Systems)다. ADEOS는 무엇보다도, 여러 개의 운영체제를 실행시키지만 마치 리눅스만 설치되어 있는 것과 같이 보이는 효과를 나타내도록 꾀한 나노커널(nanokernel)을 제공한다. ADEOS의 용도로서 주창한 것은 ADEOS를 통하여 리눅스용 실시간 응용 프로그램 인터페이스(Real Time Application Interface for Linux, RTAI)의 인터럽트를 enabled(허용)하는 것인데, 이는 http://www.aero.polimi.it/~rtai/applications를 보면 된다.
유럽 특허 1054332호는 "스위칭 단위"("switching unit")를 완전히 이해할 만큼 충분하게 설명되지 않았음)가 실시간과 범용 운영체제를 실행하는 시스템을 기술한다. 하드웨어 인터럽트는 공통 인터럽트 처리기가 처리하고, 몇몇 실시예에서는 실시간 운영체제가 처리하는데 실시간 운영체제는 이어서 보조(secondary) 운 영체제 루틴이 처리할 소프트웨어 인터럽트를 우선 순위를 낮게 부여하여 발생시킨다.
본 발명의 목적은 복수의 운영체제를 다른 용도로 설계된 경우에까지도 동시에 실행하기 위한 개선된 시스템, 방법 및 컴퓨터 프로그램을 제공하는 데에 있다. 특히 본 발명은 운영체제 중 하나(예를 들어 실시간 운영체제)가 방해받지 않고 작업을 수행하고, 다른 하나(예를 들어 범용 운영체제)는 컴퓨터의 나머지 자원을 최대한 잘 활용하며 작업을 수행하도록 하는 것을 목표로 한다.
따라서 본 발명의 일측면은 복수의 운영체제가 약간 설계 변경을 받고 거기에 공통 프로그램이 주어지되, 그 공통 프로그램에 의하여 그들 사이의 스케줄링 작업이 수행되고, 그들 중 한 운영체제("주" 또는 "핵심" 운영체제)가 다른 운영체제들("보조" 또는 "비핵심" 운영체제)에 대하여 특혜를 받는 시스템을 제공한다. 더 바람직하게는 본 발명은 하드웨어를 핵심 운영체제에 특혜적으로 할당하며, 핵심 운영체제가 접근(access)하는데 방해가 되는 보조 운영체제(들)의 접근을 인정하지 않는다. 본 발명은 더 바람직하게는 핵심 운영체제 드라이버를 사용하여 공유 자원(shared resources)에 접근하는데, 그것은 설령 보조 운영체제가 그러한 접근을 요하더라도 마찬가지이다. 그러나 미국 특허 5995745에서와 같이 핵심 운영체제가 보조 운영체제를 "실행"하는 것은 절대로 아니다. 각 체제는 실행 중에 상대 운영체제를 무시하며 오로지 공통 프로그램(선행기술의 나노커널(nanokernel)에 해당)과만 통신하는데 이 프로그램은 핵심 운영체제의 드라이버에 대한 접근을 중개한다.
보조 운영체제들은 인터럽트를 금지하지 못하도록 설계 변경되며 그들의 인터럽트 서비스 루틴은 인터럽트 발생을 가리키는 메시지에 반응하도록 설계 변경되는 것이 바람직하다. 공통 프로그램은 모든 하드웨어 예외(exception)를 주운영체제의 인터럽트 서비스 루틴에 넘김으로써 처리하고, 하드웨어 인터럽트의 대상이 보조 운영체제 둘 중 어느 하나였던 경우에는 인터럽트 메시지나 고지(notification)를 생성한다. 공통 프로그램의 스케줄링에 따라 보조 운영체제가 할당된 다음 차례에 위 메시지나 고지는 보조 운영체제로 넘겨지고 공통 프로그램은 인터럽트 서비스를 위한 루틴을 호출한다.
따라서 인터럽트 발생시에 보조 운영체제는 주운영체제(혹은 일반적으로 보조 운영체제 중 중요도가 더 높은 것)를 어떤 방식으로도 접수할 수 없는데, 이는 모든 인터럽트가 먼저 주운영체제에 의하여 처리되고 보조 운영체제에 대한 인터럽트는 주운영체제가 작업 수행을 마치고 보조 운영체제에 스케줄링에 따른 차례가 왔을 때에만 인터럽트를 보조 운영체제에 고지하기 때문이다.
따라서 이러한 인터럽트 처리는 주운영체제에 중요한 작업이 없을 때까지 미뤄진다. 그러나 결국 인터럽트 처리가 실행될 때는 보조 운영체제의 루틴들이 실질적으로 거의 변경되지 않은 채로 작동하여 그 결과 그 거동(behaviour)은 보조 운영체제로서 예측되는 바(처리가 연기된 것을 제외하고)대로 움직인다.
그러한 시스템은 이전에 출원되었던 PCT 출원인 PCT/EP04/00371에 설명되었고, 여기에 참조로 포함되었다.
본 발명은 Intel IA-32 구조에 기초를 둔 복합 명령 설정 컴퓨터 (CISC, complex Instruction Set Computer) 상의 이행과 관계 있다. CISC 프로세서들은 다중의 레지스터를 가지는데, 운영체제 사이의 스위칭에 따른 이들의 상태는 저장되고 복구될 필요가 있다. 그것들은 다중의 메모리 주소 모드를 가질 수 있고, 따라서 다른 운영체제들은 다른 모드 내에서 응용 프로그램을 실행할 수 있으며, 정교한 데이터 구조를 가질 수 있는데 이들의 상태는 저장되고 복원될 필요가 있다. 그러한 요소들은 다중의 운영체제가 동시에 그리고 안정된 방식으로 실행될 수 있는 시스템을 이루도록 하는 게 중요하다.
Intel IA-32 구조 배경기술의 이해를 돕기 위하여, 이하의 참조를 포함했다.
Intel Architecture Software Developer's Manual, Volume 1: Basic Architecture (Order Number 245470-011)
Intel Architecture Software Developer's Manual, Volume 1: Instruction Set Reference (Order Number 245471-011)
Intel Architecture Software Developer's Manual, Volume 3: System Programming Guide (Order Number 245482-011)
상기의 참조들은 모두 Intel Corporation, PO Box 7641, Mt Prospect IL 60056-7641에서 무료로 이용할 수 있고, http://intel.com 에서 다운로드 받을 수 있다.
제한 없이, 이하와 같이 혁신적인 특징 몇몇을 볼 수 있다.
A - 하드웨어 자원 디스패처(dispatcher)의 자원을 사용하는 방법을 호출함으로써 프로세서 명령을 대체한 운영체제의 응용; 두드러지나 배타적이지는 않은;
B - 다음(D)을 enabled(허용)하는(GDT와 IDT 테이블처럼) 벡터 테이블과 같이 메모리 주소 데이터 구조를 읽거나 쓰는 명령의 대체;
C - 대체한 프로세서 호출을 통해 접근하는 것을 대신한 방법으로 호출된 리눅스와 같은 운영체제를 위한 대리 데이터 구조를 제공하기 위한 원 메모리 주소 데이터 구조의 응답은 (GDT와 IDT 테이블과 같은) 하드웨어 자원 디스패처ㅁ(dispatcher)에 의한 접근을 위하여 원 메모리 주소 데이터 구조를 떠난다;
D - 하드웨어 자원 디스패처(dispatcher)를 이용한 데이터 구조 안에 있는 "공용" 또는 "공개된" 부분과 "사적인" 또는 "숨겨진" 부분의 조건
E - (알려진 바와 같이) 단일 운영체제 상의 응용 프로그램 사이 뿐만 아니라 운영체제 사이의 부동 소수점 장치(FPU, Floating Point Unit)의 "느린" 전송;
F - 운영체제 사이에서 깔끔하게 스위칭하기 위한 작업 게이트의 이용, 그리고
G - 주 운영체제와 메모리 문맥을 변화시키지 않는 하드웨어 자원 디스패처(dispatcher) 사이에서 빨리 스위칭하기 위한 작업 게이트보다 특정한 루틴 몇몇의 이용 (따라서 모든 레지스터가 저장될 필요가 없고, 스위칭은 빠르게 만든다.)
H - 인터럽트 금지로부터 보조 운영체제를 보호하는 것, 다음을 제외하는 것이 바람직하다;
I - (굉장히 짧은 기간) 작업 스위칭 동작 중 및/내지;
J- 굉장히 긴 기간인 하드웨어 자원 디스패처(dispatcher) 작동 (RS-232 통신 또는 문자열 출력과 같은) 중;
K - 문맥 스위칭을 위한 두 개의 분리된 스택 구조; 하나는 트랩을 위한 것이고 하나는 비동기 작업을 위한 것의 이용;
L - 하드웨어 자원 디스패처(dispatcher)를 실행하기 위한 주 운영체제의 관리자 문맥 일부의 이용.
서론 (Introduction)
시스템 하드웨어
본 운영체제를 적용할 수 있는 컴퓨터(100)는 인텔社 펜티엄 TM 4나 모토롤라社파워 PC(실시예에서는 양쪽 모두에 구현하였음)와 같은 중앙 처리 장치(CPU, 102)와 시스템 버스(104, 제어·데이터·어드레스 버스로 이루어진다); 그와 연결된 읽기 전용 메모리(ROM) 칩(106); 하나 또는 여러 개의 램(RAM, random access memory) 칩의 뱅크(108); 디스크 제어 장치(110, 플로피 디스크 드라이브, 하드 디스크 드라이브, DVD 드라이브와 같이 추가적이고 휴대용 미디어 드라이브에 연결된 IDE나 SCSI 제어기를 예를 들 수 있음); 하나 또는 여러 개의 입출력(I/O) 포트(112, 예를 들어 한 개나 여러 USB 포트 제어장치 및/또는 프린터 연결용 병렬 포트 제어장치 등); 내외부 주변 장치(예를 들어 PCI 버스) 연결용의 확장 버스(114); 및 여타 시스템 칩(116, 예를 들어 그래픽, 사운드 장치)을 갖추고 있다. 이러한 유형의 컴퓨터의 예로 개인용 컴퓨터, 워크 스테이션을 들 수 있다. 그러나 본 발명을 메인프레임, 제어 시스템에 내장된 마이크로컴퓨터, PDA(이 경우는 앞서 든 장치 중 디스크 드라이버 제어기와 같은 것은 빠질 수 있음) 등의 다른 컴퓨터 장치에 적용하는 것도 이하 개시하겠다.
소프트웨어 관리
도 2a를 참조할 때, 도 1의 컴퓨터(100)는 작동 중에 운영체제 커널(202, CPU가 도 1에 보인 다른 장치들에 접근할 수 있도록 출력 루틴을 제공한다), 운영체제 사용자 인터페이스 또는 X 윈도우즈와 같은 표현 층(presentation layer, 204), 미들웨어(middleware) 층(206, TCP/IP 스택과 같은 네트워크 프로토콜과 소프트웨어 제공)과 운영체제 커널(202)를 이루는 API 루틴을 호출함으로써 실행되는 응용 프로그램(208a, 208b)으로 이루어지는 상주 프로그램을 수행한다.
운영체제 커널은 다양한 작업을 하는데, 특히
。스케줄링(즉 실행 중인 응용 프로그램들 사이에 CPU와 그에 관련된 자원을 분배하는 일)
。메모리 관리(즉 각 수행 작업에 메모리를 할당하고, 필요한 경우 데이터와 프로그램을 메모리 애드온(add-on)으로부터 디스크 드라이브로 교체(swapping)하는 일)
。파일 시스템을 제공하는 일
。장치에 접근시키는 일(전형적인 예는 드라이버를 통하여)
。인터럽트 처리
。시스템 자원 및 사용자들과 응용 프로그램의 상호작용을 가능하게 하는 응용 프로그램용 인터페이스를 제공하는 일이 있다.
커널은 이른바 Unix용의 단일 커널(monolithic kernel)이어도 무방한데, 이때 장치 드라이버는 커널 자체의 일부를 이룬다. 혹은 커널을 Chorus와 같은 "마이크로커널"로 할 수 있는데. 이 경우는 장치 드라이버가 커널과 별도로 있다.
이제 컴퓨터(100)가 시작되어 사용에 들어가면, ROM(106)에 저장된 부트스 트랩(bootstrap) 프로그램이 디스크 제어장치(110)에 접근하여 디스크 영구 저장부로부터 RAM(108)으로 운영체제의 파일 처리 부분을 읽어들이게 되고, 그 다음 운영체제의 나머지 부분을 RAM(108)의 영역에 적재(load)한다. 운영체제는 그 다음 디스크 제어장치(110)를 이용하여 디스크 드라이브로부터 어떠한 응용 프로그램이라도 읽어들이고, 각 프로그램을 위하여 RAM(108)에 공간을 할당한 다음, 각 프로그램을 그 할당된 메모리 공간에 저장한다.
응용 프로그램의 작동시, 운영체제의 스케줄러(schedular) 부분은 상이한 응용 프로그램들 사이의 CPU 사용량을 분배하여, 스케줄링 방침에 따라 각각 응용 프로그램이 프로세서 시간을 나눠 가질 수 있게끔 한다. 스케줄러(schedular)는 또한 잘 안 쓰이는 응용 프로그램이나 데이터를 "교체 방출"(swapping out, 즉 그들을 RAM(108)으로부터 제거하여 메모리 공간을 비우고, 이들을 디스크에 저장)함으로써 메모리 자원의 사용을 관리한다.
마지막으로 응용 프로그램으로부터 응용 프로그램용 인터페이스(API)를 구성하는 루틴이 호출되어 입력과 출력 등의 기능을 수행하고, 운영체제의 인터럽트 처리 루틴은 인터럽트와 이벤트들에 응답한다.
도 1은 본 발명이 실행될 수 있는 컴퓨터의 구성 요소를 나타내는 블럭도이다.
도 2a는 선행기술의 소프트웨어 배치를 도시하는 그림이다.
도 2b는 본 실시예에 따른 소프트웨어의 배치를 도시하는, 2a에 대응하는 그림이다.
도 3은 도 1의 컴퓨터를 위한 도 2b의 소프트웨어를 작성하는 단계를 보여주는 흐름도이다.
도 4는 도 2b의 일부를 이루는 하드웨어 자원 디스패처(dispatcher)의 구성 요소를 보여준다.
도 5는 부팅과 초기화에 사용되는 프로그램을 도시한다.
도 6은 부팅 또는 초기화 과정에 사용되는 시스템 메모리 이미지를 도시한다.
도 7은 주운영체제로부터 보조 운영체제로 전이하는 과정을 도시한다.
도 8은 보조 운영체제로부터 주운영체제로 전이하는 과정을 도시한다.
도 9a는 본 발명에 따라 서로 다른 운영체제에서 실행되는 응용 프로그램 사이의 통신을 도시한다.
도 9b는 본 발명에 따라 서로 다른 컴퓨터상의 서로 다른 운영체제에서 실행되는 응용 프로그램 사이의 통신을 도시한다.
도 10은 주, 보조, 그리고 나노커널(nanokernel) 가상 주소 공간의 실시예를 보여준다.
도 11은 메모리 문맥이 어떻게 제시간에 스위칭되는지를 보여준다.
도 12는 커널 문맥의 보이는 부분을 나타낸다.
도 13는 커널 문맥의 숨겨진 부분을 나타낸다.
도 14는 작업 스위칭에 앞서서 초기의 TSS가 어떻게 초기화 되는지 보여준다.
도 15는 나노커널(nanokernel) TSS의 0이 아닌 필드를 보여준다.
도 16은 TSS 스택의 일반적인 상태를 보여준다.
도 17은 Intel 구조 안에 있는 세그먼테이션과 페이징이 메모리 주소에 어떻 게 사용되는지 보여준다.
도 17은 Intel 구조 안에 있는 시스템-수준 레지스터와 데이터 구조를 나타낸다.
첨부된 도면을 참조하면서 본 발명의 실시예들을 기술하기로 한다. 이는 어디까지나 예시일 뿐이다.
모범 실시예의 원리 요약
모범 실시예에서 도 1의 컴퓨터(100)에 사용될 각 운영체제(201, 202)에는 약간의 설계 변경이 가해지고, 낮은 수준의 새 프로그램(400, 여기서 "하드웨어 자원 디스패처(dispatcher)"로 명명한다, 비록 운영체제의 커널은 아니지만 때때로 "나노커널(nanokernel)"로 불리기도 한다)이 신설된다. 하드웨어 자원 디스패처(dispatcher)(400)는 CPU(102)와 상호작용을 하므로 CPU의 특정 형태에 맞춤식으로 되어 있다. 또한 곧 밝힐 명백한 이유에 따라 설계 변경되는 운영체제(201, 202)의 버전 역시 하드웨어에 따라 맞추게 된다.
하드웨어 자원 디스패처(dispatcher)(400)는 그 자체로는 운영체제가 아니다. 디스패처(dispatcher)는 응용 프로그램과는 전혀 상호작용하지 않으며, 매우 제한된 기능을 가지고 있다. 디스패처(dispatcher)는 비록 대부분의 계산 작업 (processing)을 운영체제에 맡기며 프로세서에서 운영체제의 기계어 코드(native code)를 그대로 수행하지만 디스패처(dispatcher)가 협동 작업을 하기 위하여서는 운영체제를 변경하여야 하므로 가상 머신은 물론 에뮬레이터(emulator)도 아니다. 디스패처(dispatcher)는 아래의 기초적인 기능을 수행한다.
。복수의 운영체제들 각각을 적재하고 시작한다.
。메모리와 다른 시스템 자원을 각 운영체제에 할당한다.
。서로 다른 운영체제들의 작동에 대한 스케줄링을 한다(즉 그들 사이에 CPU 시간을 분배하고 운영체제 사이에 일어나는 변경을 관리한다.)
。운영체제들이 나누어 사용하여야 하는 시스템 장치들에 간접적으로 접근하는 방식인 "가상화 장치(virtualised device)"를 제공한다(장치의 "가상화")
。서로 다른 운영체제상에서 실행되는 응용 프로그램들끼리 통신할 수 있도록 운영체제들 사이에 통신 연결을 제공한다.
실시예에서 운영체제는 같은 대우를 받지 않는다. 대신 운영체제 중 하나를 핵심 운영체제(이것이 실시간 운영체제가 됨)로 삼으며 나머지 운영체제는 "비핵심" 또는 "보조" 운영체제(이는 리눅스와 같은 범용 운영체제가 됨)가 된다.
하드웨어 자원 디스패처(dispatcher) 설계시, 사용가능한 시스템 자원(즉 장치와 메모리)를 기재한 데이터 구조(예를 들어 테이블)가 제공되어, 정적으로 할당(static allocation)할 수 있는 가능한 한 많은 시스템 장치를 운영체제 중 배타적 으로 어느 하나나 다른 쪽에 정적으로 할당되게끔 한다. 예를 들어 병렬 프린터 포트는 범용 운영체제(202)에 정적으로 할당될 수 있고, 이 운영체제는 프린터 출력에 필요한 응용 프로그램을 실행하게 된다. 다른 한편으로 ISDN 디지털 라인 어댑터 포트는 통신을 위하여 실시간 운영체제(201)에 영구 할당될 수 있다. 장치를 가능한 한 이렇게 정적으로 할당하는 것은 각 운영체제가 자신의 기존 드라이버를 사용하여 정적으로 할당된 장치를, 하드웨어 자원 디스패처(dispatcher)를 호출할 필요 없이 접근하는 것이 가능함을 뜻한다. 그러므로 그러한 장치에 접근하는 데에 따른 실행 속도의 저하(가상 머신이나 에뮬레이터와 같이 작동할 경우에 일어날 수 있는)가 없어진다.
반드시 공유되어야 하는 시스템 장치의 경우에 하드웨어 자원 디스패처(dispatcher)는 비핵심 운영체제에 의한 장치 사용을 가상화하고, 핵심 운영체제에 공급된 드라이버를 사용함으로써 장치에 대한 접근을 수행한다. 마찬가지로 인터럽트 처리에서는 인터럽트가 핵심 운영체제의 인터럽트 루틴으로 넘겨지고, 루틴은 인터럽트를 처리하거나(인터럽트 대상이 핵심 운영체제일 때), 하드웨어 자원 디스패처(dispatcher)를 통하여 비핵심 운영체제로 전달된다(인터럽트 대상인 그 운영체제일 때).
부팅시 하드웨어 자원 디스패처(dispatcher)를 먼저 적재(loading)하고, 디스패처(dispatcher)는 다시 각각의 운영체제들을 미리 예정된 순서, 핵심 운영체제 부터 시작해서 차례로 각 보조 운영체제로 가는 순에 따라 적재한다. 핵심 운영체제는 테이블 기재에 따라 필요한 자원을 배분받으며, 작동할 수 있는 고정 메모리 공간을 소유하고 있다. 각 보조 운영체제는 다시 가용할 수 있는 남은 자원으로부터 필요한 자원과 메모리 공간을 할당받는다. 따라서 실시예에서는 각 운영체제에 고유의 메모리 공간을 할당하고 장치의 독점적인 정적할당을 통하여 운영체제가 사용하는 자원들은 물리적으로 가능한 한 최대로 분리되고, 필수적으로 공유하여야 하는 장치들만이 공유된다.
작동시에 하드웨어 자원 디스패처(dispatcher)의 스케줄러(schedular)는 핵심 운영체제가 자신의 수행 작업을 마칠 때까지 실행되도록 하여 주며, 그 다음에는 차례로 각 비핵심 운영체제로 제어 기능을 넘겨 다음 인터럽트나 이벤트가 발생할 때까지 실행되게 한다. 그러므로 실시예의 시스템은 핵심 운영체제의 작동이 실질적으로 불변(핵심 체제가 자신의 고유한 드라이버를 사용하고, 어떠한 인터럽트나 이벤트 처리에 대해서도 가장 먼저 접근할 수 있으므로)하는 다중 운영체제 환경을 가져다 준다. 보조 운영체제들은 남은 프로세서 시간의 한도 내에서 효율적으로 작동할 수 있는데, 이는 대부분의 경우 그들이 고유한 전용 드라이버와 다수의 시스템 장치에 대해 독점적으로 접근할 수 있기 때문이다. 최종적으로 하드웨어 자원 디스패처(dispatcher)는 제한된 기능들을 처리할 뿐이므로 그 자체가 작은 프로그램이어도 되는데, 이에 따라 시스템 자원이 절약된다.
모범 실시예는 또한, 만들고 유지하는 데 경제적인데, 이는 이미 특정 컴퓨터(100)에 맞춰진 표준적인 시판 운영체제에 제한적인 변화를 주는 것만으로 족하기 때문이다. 나아가, 운영체제의 변경 사항이 특정한 유형의 컴퓨터(100)와 인터페이스를 이루고 운영체제의 여타 부분과 같이 자주 바뀔 가능성이 적은, 인터럽트 처리나 초기화 시간에서의 컴퓨터 배치(configuration)와 같은 설계특정적(architecture-specific) 파일 처리 관련 문제에 국한되기 때문에, 똑같은 운영체제의 새 버전을 다중 운영체제 방식에서 작동하게끔 고쳐 주는데 드는 수고가 거의 없다.
모범 실시예에 대한 자세한 기
이 실시예에서 컴퓨터(100)는 인텔 386계열 프로세서(예를 들어 펜티엄 프로세서) 컴퓨터(단계 302)이다. 핵심 운영체제(201)는 C5 운영체제(ChorusOS 체제의 제5세대 공개 소스 버전인 Jaluna-1의 실시간 마이크로커널, 공개 소스로 다음 주소에서 무료로 내려받기, http://www.jaluna.com)이다.
단계 306에서 Chorus운영체제 커널(201)은 다중 운영체제 방식하에서 작동하도록 조절되는데, 이는 새로운 플랫폼에 이식하는 일(즉 CPU는 같지만 시스템 장치들은 다른 새 컴퓨터에서 실행가능하도록 새 보드 지원 패키지(BSP, board support package)를 쓰는 일)과 마찬가지 방식으로 다뤄진다. 부팅과 초기화 순서(initialization sequence)는 실시간 운영체제가 그 자신이 스스로 시작하지 않고, 하드웨어 자원 디스패처(dispatcher)가 그 운영체제에 할당된 메모리 공간에서 시작될 수 있도록 조절된다. 초기화 순서의 하드웨어 검색 단계는 핵심 운영체제가 다른 보조 운영체제에 할당된 하드웨어 자원에 접근하지 못하게끔 조절된다. 핵심 운영체제는 하드웨어 자원 디스패처(dispatcher)를 통하여 정적 하드웨어 할당 테이블 내용을 파악하고 사용 가능한 장치들을 감지하게 된다.
트랩 호출(trap call, 2012)은 상태를 감지하고 그에 따른 어떠한 조치를 요구하기 위하여 핵심 운영체제에 추가된다. 여기서 트랩 호출이란 컴퓨터로 하여금 현재 문맥(context, 즉 레지스터들의 상태)을 저장하고 새로운 문맥을 적재하도록 하는 호출을 말한다. 가상 메모리 주소지정이 쓰였을 때는 따라서 주소 포인터는 바뀌게 된다. 예를 들어 실시간 운영체제(201)이 종착점에 도달한 (그리고 프로세서 자원을 사용할 필요가 없어진) 때는 제어 기능이 다시 하드웨어 자원 디스패처(dispatcher)에 되돌려지고, "유휴(idle)" 트랩 호출을 발하여 보조 운영체제를 시작할 수 있다. 많은 프로세서들은 "정지(halt)" 명령을 가지고 있다. 몇몇 경우에 감독자 수준의 코드(예를 들어 응용 프로그램이 아니라 운영체제)만이 그러한 "정지" 명령을 포함할 수 있다. 이 실시예의 경우 모든 운영체제에서 "정지" 명령이 삭제되고 "유휴" 루틴(예를들어 수행 쓰레드)로 바뀌는데, 이 루틴이 호출되면 "유휴" 트랩 호출을 하게 된다.
몇몇 BSP 드라이버는 보조 운영체제를 위한 공유 장치를 가상화하는데 하드웨어 자원 디스패처(dispatcher)를 보조하기 위하여 특별히 맞춰졌다. 운영체제로 서는 입출력(I/O) 버스에 대한 접근을 제공하는 것처럼 보이는 추가적인 "가상" 드라이버(2014)가 새로 추가되어, 버스로 하여금 데이터를 작성할 수 있게 한다. 실제로 가상 버스 드라이버(2014)는 메모리를 통신 매개 수단으로 사용한다. 가상 버스 드라이버는 개인 메모리(private memory, 입력 데이터용) 얼마간 내보내기(export)하고 다른 운영체제가 내보내기한 메모리(출력 데이터용)를 가져오기(import)한다. 이렇게 하여 운영체제(201, 혹은 그 운영체제에서 실행되는 응용 프로그램)는 다른 운영체제로(또는 그 안에서 실행되는 응용 프로그램) 마치 서로 다른 컴퓨터 장치에서 실행되고 실제 I/O 버스로 연결된 두 운영체제 사이처럼 데이터를 넘길 수 있다.
보조 운영체제(202)는 커널 버전이 2.4.18인 리눅스로 선택하였다(단계 308). 단계 310에서 보조 운영체제 커널(202)은 다중 운영체제 환경에서 기능할 수 있도록 변경되는데, 다중 운영체제 환경은 새로운 하드웨어 구조로 취급된다. 단계 306에서와 같이, 부팅과 초기화 순서는 변경되는데, 보조 운영체제를 하드웨어 자원 디스패처(dispatcher)가 시작할 수 있게 하고, 보조 운영체제가 하드웨어 원 디스패처(dispatcher) 테이블에서 다른 운영체제에 할당된 것으로 명시된 하드웨어 자원들에 접근하지 못하도록 변경된다. 단계 306에서처럼 트랩 호출(2022)이 추가되어 하드웨어 자원 디스패처(dispatcher)로 제어 기능이 넘겨진다.
공유 시스템 장치의 고유(native) 드라이버는 하드웨어 자원 디스패처(dispatcher)에 의하여 가상화된 장치들(인터럽트 제어기, I/O 버스 브리지, 시스템 타이머, 실시간 클럭)을 다루는 새 드라이버(2028)로 교체된다. 이들 드라이버 는 컴퓨터(100)의 해당 장치에 대한 몇 가지 연산을 수행하기 위하여, 하드웨어 자원 디스패처(dispatcher)의 가상 장치 처리기(416)를 호출한다. 하드웨어 자원 디스패처(dispatcher)의 그러한 가상 장치 처리기(416) 각각은 핵심 운영체제의 "동료(peer)" 드라이버 루틴과 짝지어지는데, 이 루틴은 시스템 장치와 직접 상호작용하도록 마련되었다. 따라서 가상 장치 처리기에 대한 호출은 실제 장치에 대한 접근을 위하여 해당 가상화 장치용의 핵심 운영체제의 동료 드라이버로 연계(relay)된다. 단계 306과 같이 해당 가상 I/O 버스에 대한 읽고 쓰기용(read and write) 드라이버(2024)가 제공되어 운영체제간 통신을 할 수 있다.
보조 운영체제의 인터럽트 서비스 루틴은 해당 가상 인터럽트(하드웨어 자원 디스패처(dispatcher)의 인터럽트 처리 루틴(412)에 발한 호출의 형태)에 대응하는 각각의 가상 인터럽트 서비스 루틴(2026)을 제공하기 위하여 변경되는데. 그에 의하여 실제 인터럽트나 이벤트에 반응하지 않게 된다. 보조 운영체제의 루틴(인터럽트 서비스 루틴 포함) 역시 하드웨어 인터럽트의 금지(masking, 적어도 핵심적인 연산을 제외한 모든 루틴에 대하여)를 해제하도록 바뀐다. 그리하여 핵심 운영체제(201)가 보조 운영체제(202와 여타)들을 접수할 수 있게 된다. 다시 말해서, 가상 인터럽트에 대한 보조 운영체제의 응답 자체가 핵심 운영체제(201)에 대한 실제 인터럽트에 의하여 차단될 수 있다. 이에는 전형적으로 다음의 경우들이 속한다.
。금지(mask)하거나 금지 해제하는 이벤트(프로세서 수준의 인터럽트)
。금지 상태를 저장하고 복원하는 이벤트
。인터럽트 원인을 파악하는 작업(인터럽트 제어 장치)
。소스 수준에서 인터럽트의 금지 또는 금지 해제 (인터럽트 제어 장치)
공유 하드웨어 장치(I/O 버스 브리지, 시스템 콘솔, 시스템 타이머와 실시간 클럭)에 접근하기 위하여 새 가상 장치 드라이버(2028)이 추가된다. 이들 드라이버는 컴퓨터(100)의 해당 장치로부터 데이터를 읽고 장치에 데이터를 써 넣기 위하여 하드웨어 자원 디스패처(dispatcher)의 가상 장치 처리기(416)를 호출한다.
이러한 기능을 가질 수 있도록 본 실시예에서 리눅스 커널(2070)은 가상 하드웨어 자원 디스패처(dispatcher) 구조 서브트리(subtree)(I-386과 파워PC 변형물용의 nk-i386과 nk-ppc)를 추가하여 변경되는데, 이 때 소수의 변경된 파일도 추가된다. 변경되지 않은 파일은 기존 형태 그대로 재사용된다. 원래의 서브트리는 유지되지만 사용되지는 않는다.
단계 312에서 하드웨어 자원 디스패처(dispatcher)(400)가 작성된다. 하드웨어 자원 디스패처(dispatcher)는 다음의 기능을 하는 루틴(도 4 참조)을 제공하는 프로그램 코드를 갖춘다.
。 자신을 부팅하고 초기화하는 기능(402)
。하드웨어 자원(포트와 같은 장치)의 리스트와 각 자원이 해당 운영체제에 유니크하게 배당된 사항을 나타내는 할당 항목(allocation entry)을 담은 테이블을 저장하는 기능(403)
。하드웨어 자원 디스패처(dispatcher) 할당(allocation) 테이블을 완성하는 핵심 운영체제를 부팅하고 초기화하는 기능(404)
。보조 운영체제들을 부팅하고 초기화하는 기능(406)
。운영체제 사이의 스위칭(switching) 기능(408)
。운영체제 사이의 스케줄링 기능(410)
。인터럽트 처리(412, 실시간 운영체제 인터럽트 서비스 루틴을 사용하고, 보조 운영체제의 가상 인터럽트 서비스 루틴에 데이터를 공급)
。각 운영체제로부터의 트랩 호출을 처리하는 기능(414)
。공유 장치들에 대한 보조 운영체제의 접근을 처리하는 기능(416)
。가상 I/O 버스상에서 운영체제간의 통신을 처리하는 기능(418)
이하 기재할 실시예들에서는 디스패처(dispatcher)가 디버깅 프레임워크도 제공할 수 있다.
운영체제 스위칭기(408, switcher )
한 운영체제에서 다른 운영체제로 스위칭하기 위하여서 운영체제 스위칭기(408)는 현재 실행 중인 운영체제의 "문맥(context)"-레지스터 값과 같은 상태 변수 집합의 현재값-을 저장하고, 다른 운영체제의 저장된 문맥을 복원하며 다른 운영체제가 바로 그 전 상태에서의 작업 수행을 재개하는 호출을 하도록 설정된다. 프로세서가 메모리의 세그먼트나 가상 혹은 간접 주소 지정 테크닉을 사용하는 때에는, 현 메모리 공간에 대한 포인터를 저장하는 데이터 구조나 레지스터에서 따라서 교체(swapping)가 일어난다. 예를 들어 각 운영체제는 그러한 서로 다른 메모리 공간에서 작동하는데, 이 메모리 공간은 그 공간에 대한 포인터 값을 포함하는 문맥에 의하여 정의된다.
구체적으로 스위칭기는
。현재 운영체제가 유휴 상태에 들어가면 현 운영체제로부터 스케줄링 상 다음으로 예정된 운영체제로의 명시적(explicit) 스위칭 기능(예를 들어 트랩 호출)을 수행하거나,
。하드웨어 인터럽트가 일어나면 보조 운영체제로부터 핵심 운영체제로 암시적(implicit) 스위칭 기능을 수행한다. 스위칭 기능은 이하 기술하는 것처럼 트랩 호출이나 실제 혹은 가상 인터럽트시에도 일어날 수 있다.
스케줄러( schedular )(410)
스케줄러(schedular)(410)는 한 운영체제를 마치고 나서 어느 보조 운영체제(보조 운영체제가 여럿일 때)로 스위칭할지를 선택함으로써 각 운영체제에 사용 가능한 프로세서 시간의 일부를 할당한다. 본 실시예에서 각 운영체제는 고정된 우선 순위 스케줄링에 따라 선택된다. 시간 공유(time sharing)나 프로세서 시간 최소분률 보증 방식(guaranteed minimum percentage)에 따른 선택 기준을 제시하는 다른 실시예도 이하 검토한다. 그러나 각 경우에 핵심 운영체제는 유휴 상태에 있을 때에만 접수당한다.
다음의 실시예에서 핵심 운영체제는 스케줄러(schedular)(410)에 명시적으로 보조 운영체제가 자신을 접수할 수 있는 시간을 알려서, 핵심 운영체제에서 수행되고 있는 작업보다 더 높은 우선순위로 보조 운영체제가 작업 수행을 할 수 있도록 모든 보조 운영체제가 CPU에 접근하는 것을 얼마간 enabled(허용)할 수 있다. 따라서 한 실시예에서 핵심 운영체제의 인터럽트 서비스 루틴은 접수당하지 않기 때문에 그 결과 핵심 운영체제가 외부 이벤트나 실시간 클럭이 제공하는 타이밍 신호에 언제나 응답할 수 있게 되어 실시간 작동을 유지하게 된다.
가상화 프로세서 예외의 처리
하드웨어 자원 디스패처(dispatcher)는 다음과 같이 프로세서 예외(exception)(일례로 CPU 인터럽트 또는 코프로세서 인터럽트)를 처리하는 메커니즘을 제공하도록 마련되었다.
。먼저 핵심 운영체제를 통하여 프로세서 예외(exception)를 인터셉트하고,
。둘째로 하나 또는 여럿의 보조 운영체제에 상응하는 가상 예외(exception)를 고지하고, 해당 보조 운영체제를 스케줄러(schedular)가 다음에 호출할 때 그 데이터를 저장하며, 해당 보조 운영체제에서 대응하는 가상 인터럽트 서비스(2026)를 호출하고,
。셋째로 보조 운영체제에서 발생한 pending(미결) 가상 예외(exception)를 모두 금지하거나 금지 해제한다.
가상화된 예외(exception)는 전형적으로 다음과 같이 두 경우에 쓰인다.
。첫째로 보조 운영체제에 하드웨어 장치 인터럽트(비동기(asynchronous) 프로세서 예외(exception)의 형식으로 배달됨)를 전달하는 경우
。둘째로 운영체제간 교차 인터럽트, 즉 한 운영체제에 의하여 상대방 인터럽트(비동기 예외(exception)의 형식으로 배달됨)용으로 생성된 인터럽트를 구현하는 경우
트랩 호출 처리기(414)
다음 기재를 읽으면 트랩 호출 처리기의 작동이 명백해질 것이다. 트랩 호출 처리기의 주된 목적은 한 운영체제가 정지(그리고 따라서 CPU 자원을 쓸 필요 없을 때)되었을 때 스케줄러(schedular)와 스위칭기가 운영체제를 다른 것으로 바꿀 수 있게 하는 데 있다. 부가적인 역할은 시스템 콘솔과 같은 하드웨어 자원 디스패처(dispatcher) 서비스를 후속 실시예들에서 논할 방식과 같이 디버깅용으로 쓰기 위하여 불러내는 데 있다.
가상화 장치(416)
앞서 밝힌 바와 같이 각 운영체제는 각 공유 장치(예를 들어 인터럽트 제어기, 버스 브리지, 시스템 타이머, 실시간 클럭)마다 디바이스 드라이버를 제공하여 그 장치에 대한 동료 수준(peer level) 드라이버 집단을 형성한다. 실시간 운영체제는 실제로 해당 장치에 접근하는 데 쓰이는 드라이버를 제공하고, 나머지 운영체제는 가상 장치 드라이버를 제공한다.
하드웨어 자원 디스패처(dispatcher)의 공유 장치 처리기(416)는 그 장치의 모든 동료 장치(peer device)가 접근할 수 있는 각 장치를 위한 저장된 데이터 구조를 공급한다. 해당 장치에 접근할 때나 혹은 이미 접근한 때에는, 그 장치 드라이버가 접근한 세부 기록을 가지고 해당 데이터 구조에 저장된 자료를 갱신한다. 동료 드라이버들은 교차 인터럽트(앞서 설명한 바대로)를 사용하여 해당 데이터 구조가 막 갱신되었다는 이벤트를 다른 동료 드라이버에 고지하는 신호를 보낸다.
인터럽트 제어 장치에 접근하는데 쓰이는 드라이버는 앞서 설명한 가상화 예 외(exception) 메카니즘을 사용하여 아래와 같이 하드웨어 인터럽트를 처리한다.
。핵심 운영체제 장치 드라이버는 하드웨어 인터럽트를 처리하고 보조 운영체제의 동료 드라이버에게 가상화된 예외(exception)로서 전달한다.
。보조 운영체제는 그 가상화된 예외(exception)를 금지하거나 금지 해제하는 루틴(앞서 설명)을 사용하여 인터럽트를 enabled(허용)하거나 enabled(허용)하지 않는다.
I/O 버스들과 그들의 브리지를 공유하는 것은 그에 연결된 장치들이 모두 같은 운영체제에 할당되지 않았을 때에만 필요하다. 따라서, 장치를 할당할 때, 가능한 한 같은 I/O 버스에 연결된 장치들은 같은 운영체제에 할당된다. 공유가 필요한 곳에는 자원 할당 테이블(404)이 버스에 대한 자원(주소 공간, 인터럽트 라인, I/O 포트) 할당을 가리키는 디스크립터(descriptor) 데이터를 저장하여 어느 운영체제가 어느 자원을 가지는지 가리켜 준다.
실시예의 구현
최종적으로 단계 314에서 하드웨어 자원 디스패처(dispatcher)와 운영체제를 위한 코드는 컴퓨터(100)에 제공되는 배분 가능한 이진 컴퓨터 프로그램 결과로서 변환 컴파일(compile)된다.
본 발명의 한 측면으로서 공급할 수 있는 것은 개발 환경 제품(development environment product)으로서, 사용자로 하여금 사용할 서로 다른 운영체제들을 직접 선택할 수 있고 각 운영체제용의 응용 프로그램을 선택하고 개발할 수 있게 하 며, 응용 프로그램과 운영체제를 양도 가능한 제품으로 통합하고, 운영체제를 부팅하며, 수행 가능한 응용 프로그램 2진수 코드를 시작(launch) 할 수 있는 컴퓨터 프로그램이다. 이는 www.jaluna.com에서 구할 수 있는 C5 개발 환경에 기초하였고 또 그와 유사하다.
부팅과 초기화시 실시예의 작동
도 5에 따른 본 실시예의 부팅과 초기화 프로세스는 아래와 같이 이루어진다.
ROM(106)에 저장된 부트스트래핑용 프로그램(4022, trampoline)이 처음으로 전원이 공급되면 가장 먼저 수행되고, 이 프로그램은 다시 하드웨어 자원 디스패처(dispatcher) 프로그램(400)의 나머지 부분을 메모리에 설치하는 프로그램(4024)를 시작하는데. 이 프로그램은 또 디스패처(dispatcher)를 시작하여 시스템 이미지 배치를 기술하는 데이터 구조(아래 설명)를 한 인자(argument)로 넘기게 된다.
하드웨어 자원 디스패처(dispatcher)는 시스템 콘솔로 사용될 수 있는 직렬 회선(serial line)을 초기화한다. 이어서 핵심 운영체제부터 시작하여 각 운영체제에 차례로 메모리 공간(운영체제 환경)을 할당한다. 하드웨어 자원 디스패처(dispatcher)는 따라서 제2수준의 시스템 커널 부트 로더(second level system kernel loader)로 작용한다.
각 운영체제 커널은 이어서 자신의 초기화 단계에 접어들어 자원 할당 테이블(404)에 남아 있는 자원 중에서 자신이 독점할 자원들을 선택하고 초기 서비스와 응용 프로그램들을 시작한다.
도 6은 시스템 이미지를 형성하는 메모리 주소 할당의 사례를 도시한다. 하드웨어 자원 디스패처(dispatcher)와 운영체제가 변형 컴파일(compile)될 때 메모리 내의 특정 위치가 할당한다. 도 6에 나타낸 바처럼, 메모리 내의 이들 위치의 모임이 시스템 이미지를 규정한다. 시스템 이미지는 하드웨어 자원 디스패처(dispatcher)(602)가 위치한 제1 메모리 뱅크(602), 실시간 운영체제가 위치한 제2 메모리 뱅크(604), 보조 운영체제가 위치한 제3 메모리 뱅크(606), 그리고 이 실시예에서는 보조 운영체제(리눅스)의 루트 파일 시스템을 담은 RAM 디스크가 위치한 제4 메모리 뱅크(608)로 구성된다.
시스템 이미지는 영구 저장장치(즉 휴대전화나 PBX와 같은 전형적인 실시간 장치를 위한 읽기 전용 메모리)에 저장된다. 남은 메모리 뱅크는 각 운영체제가 응용 프로그램을 적재하고 실행할 수 있는 환경으로서 각 운영체제에 할당된다.
운영체제 문맥을 위한 메모리 할당
부팅되는 동안, 각 운영체제는 자신의 설정에 따라 필요한 총 메모리 용량을 만족하기 위하여 그에 맞는 메모리 공간을 할당한다. 메모리 뱅크를 운영체제에 할당한 이후에는 운영체제 자체의 물리적 메모리 관리 지침(management scheme)을 통하여 관리한다. 운영체제는 모든 다른 메모리를 무시한다.
가상 메모리 할당
각 운영체제는 서로에 의하여 또는 하드웨어 자원 디스패처(dispatcher)나 서로에 의하여 간섭되지 못하도록 각각 별도의 가상 메모리 공간을 할당 받는다. 각 운영체제의 사용자 주소 공간(즉, 레인지(range))과 관리자(supervisor) 주소 공간(즉 레인지)은 서로 다른 메모리 관리 장치(MMU, memory management unit) 문맥 식별자(ID, identifier)을 할당받는데, 이들은 주소가 겹치는 서로 다른 가상 메모리 공간을 구별할 수 있게 하여 준다. MMU 문맥 ID는 운영체제가 변환 컴파일(compile)될 때 각 운영체제에 지정된다.(도 3의 단계 314)
이러한 해결책을 쓰면 하드웨어 자원 디스패처(dispatcher)가 서로 다른 운영체제 사이를 스위칭할 때 변환 캐시(translation cache, TLB)를 내보낼(flush) 필요가 없고, 따라서 시간을 절약하게 된다. 대신 다른 운영체제 사이를 스위칭하는 작업은 현재 기능 중인 운영체제의 MMU 문맥 ID를 저장하고, 바꿀 운영체제의 이전에 저장되었던 MMU 문맥 ID를 재호출(recall)하는 것으로 이루게 된다.
입/출력 장치의 할당
앞서 설명한 것처럼, 할당 테이블(404)은 각 운영체제에 어떠한 장치가 유니크하게 할당되는지 가리켜 준다. 게다가 테이블(404)은 그러한 장치에 어느 입/출력 자원(직접 메모리 접근(direct memory access, DMA) 장치, 입/출력 포트, 인터럽트 등)이 할당되었는지 독점적으로 가리켜 주므로, 이들 자원을 어떠한 충돌 없이 직접 사용할 수 있게 한다. 전형적으로는 많은 장치들이 중복(duplication)되는바, 이 방식에 의하여 잠재적인 충돌을 상당히 줄일 수 있다.
분배 방식은 운영체제 설정 지침(예를 들어 C5의 경우, 장치들은 장치 트리(tree)에 명시된다)에 바탕을 둔다. 부팅시 장치를 운영체제에 할당하고, 또 부팅의 순서대로 할당이 일어나므로, 핵심 운영체제는 테이블(404)에 기재된 가용 장치에 대한 첫 번째 선택권을 가지며, 보조 운영체제들은 차례로 남은 장치들을 할당받는다. 각 운영체제가 초기화되면서 각 운영체제는 이 장치들을 감지하고, 하드웨어 자원 디스패처(dispatcher)와의 상호작용 없이도 장치에 대한 고유한 드라이버를 사용한다.
보조 운영체제의 핫( hot ) 재부팅
본 실시예에서는 다른 운영체제를 계속 실행하면서 보조 운영체제를 재부팅(예를 들어 시스템 장애때문에)할 수 있다. 시스템 자원을 분리하였으므로 보조 운영체제의 시스템 장애(crash)로 핵심 운영체제(또는 다른 보조 운영체제)의 계속된 실행을 방해하지 않으며, 그 보조 운용체제의 재부팅의 경우에도 마찬가지이다.
본 실시예에서 하드웨어 자원 디스패처(dispatcher)에 대한 운영체제의 “중단”과 “시작” 트랩 호출은 핵심 운영체제로부터 보조 운영체제를 종료하고 다시 시작하는 것을 돕는다. 덧붙여서 하드웨어 자원 디스패처(dispatcher)는 부팅시 원래의 시스템 이미지 사본을 하드웨어 자원 디스패처(dispatcher)에 할당된 메모리 내의 영구 메모리에 저장한다. 한 예제로서 이 실시예의 핫(hot) 재시작은 다음과 같이 관리된다.
처음 부팅할 때, 하드웨어 자원 디스패처(dispatcher)는 해당 보조 운영체제 메모리 이미지의 사본을 저장한다. 핵심 운영체제는 보조 운영체제의 작동을 주기적으로 감시하기 위한 소프트웨어 감시 드라이버 루틴(예를 들어 보조 운영체제의 연속적인 작동을 점검하기 위하여 타임아웃을 설정하고 보조 운영체제에서 실행 중인 동료 드라이버가 유도한 이벤트를 기다리기)을 가지고 있다.
핵심 운영체제가 보조 운영체제의 작업 수행 실패나 중지를 감지하면 하드웨어 자원 디스패체에게 (그 보조 운영체제의) “중단” 그리고 그 다음에 “시작” 트랩 호출을 하게 된다. 하드웨어 자원 디스패처(dispatcher)는 그 보조 운영체제의 시스템 이미지 사본을 복원하고 메모리로부터 재부팅하여 그 보조 운영체제를 재시작한다. 테스트의 검사 결과에 의하면 리눅스 보조 운영체제는 잠금(locking up) 후 몇 초안에 재부팅할 수 있음을 알 수 있었다.
한편으로 핫 재시작은 Chorus 운영체제의 방식으로부터 개발된 것인데, Chorus 체제의 방식은 예를 들어 F. Hermann Abrossimov, J.C. Hugly 外 1996년 8월 Chorus Sytstems Inc. 기술 보고서 14쪽 “Fast Error Recovery in CHORUS/OS. The Hot-Restart Technology"에 기재되어 있고, 이는 http://www.jaluna.com/developer/papers/CSI-TR-96-34.pdf에서 얻을 수 있다.
실행 시간( Run - time ) 작동
설치와 부팅 후 본 실시예의 작동에 대해서 자세하게 설명한다.
부팅과 초기화가 된 뒤 실시간 운영체제는 하나 또는 여러 개의 응용 프로그램(207, 예를 들어 UDP/IP 스택, Universal Datagram Protocol/Internet Protocol)을 수행하고 보조 운영체제는 몇 개의 응용 프로그램(208a, 208b, 예를 들어 문서 편집기와 스프레트시트)을 수행한다. 실시간 운영체제 마이크로커널(201)과 보조 운영체제 커널(202)은 하드웨어 자원 디스패처(dispatcher) 인터페이스를 통하여 하드웨어 자원 디스패처(dispatcher)와 통신하는데, 하드웨어 자원 디스패처 인터페이스는
。운영체제 문맥(즉 운영체제를 스위칭하기 위하여 저장하고 복원하여야 되는 상태 변수의 모임)과 하드웨어 저장소(repository)를 나타내는 데이터 구조
。운영체제 환경에서 수행되는 함수의 모임
。하드웨어 자원 디스패처(dispatcher) 환경에서 수행되는 트랩 호출 루틴의 모임을 갖추고 있다.
운영체제 중 어느 쪽도 프로세서 시간을 요하지 않는 때(예를 들어 양쪽 모두 “대기(wait)” 상태에 도달한 때)에는 하드웨어 자원 디스패처(dispatcher)(400)가 핵심 운영체제의 유휴 스레드(thread)로 스위칭하는데, 여기서 인터럽트나 이벤트를 기다리게 된다. 따라서 핵심 운영체제의 서비스 루틴은 핵심 운영체제로 먼저 스위칭할 필요 없이 곧바로 인터럽트를 처리할 수 있다. 이 과정에서 언젠가는 인터럽트나 이벤트가 일어난다. 예를 들어 데이터 포트에서 패킷(packet)을 수신하면, UDP/IP 스택을 수행하는 실시간 운영체제가 이를 처리할 수 있도록 하기 위하여 인터럽트를 유발한다. 대신에 사용자는 키보드나 마우스를 조 작하여, 문서 편집기(208)와 상호작용하는 보조 운영체제(202)의 GUI를 작동하게끔 인터럽트를 유발 할 수도 있다. 혹은 시스템 클럭이 미리 예정된 시간이 경과되면 응용 프로그램이 작업 재수행을 개시하여야 함을 알리거나, 해당 운영체제가 기능을 수행하여야 한다고 지시할 수도 있다.
핵심 운영체제 서비스 루틴은 그 다음, 아래에 설명된 대로 인터럽트를 서비스한다.
인터럽트와 이벤트 처리
이미 핵심 운영체제에 진입하지 못했다면, 하드웨어 자원 디스패처(dispatcher) 인터럽트 처리기(412)는 운영체제 스위칭기(408)를 호출하여 핵심 운영체제로 스위칭하고 그 다음 핵심 운영체제(201)의 인터럽트 처리 루틴, ISR(412)을 호출한다. 핵심 운영체제에 고유하게 설계된 장치에서 비롯되었거나, 또는 미리 예정된 특정한 값을 가지는 공유장치에서 비롯되었기 때문에 인터럽트가 핵심 운영체제를 목적으로 하는 것일 경우, 핵심 운영체제 인터럽트 서비스 루틴은 인터럽트의 처리에 필요한 조치를 취한다. 그렇지 않은 경우, 제어 기능은 하드웨어 자원 디스패처(dispatcher)로 다시 넘어간다.
핵심에서 보조 운영체제로의 스위치
도 7을 참조할 때, 이 실시예에서 시스템은 핵심 운영체제(201)에서 구동되 는 응용 프로그램(207a)의 스레드(702)를 실행하고 있다. 인터럽트가 일어나면 핵심 운영체제 인터럽트 서비스 루틴(ISR, 704)이 인터럽트를 서비스한다. 완료시에는 제어 기능이 다시 스레드(702)와 핵심 운영체제(201) 스케줄러(schedular)가 수행하는 나머지 스레드 중 어느 것으로라도 넘어가게 된다. 모든 스레드의 처리가 끝나면, 핵심 운영체제는 수행을 마치고 자신의 "유휴" 스레드를 스케줄링한다. 그에 따라 핵심 운영체제의 "유휴" 트랩 루틴은 하드웨어 자원 디스패처(dispatcher)(400)에 "유휴" 트랩 호출을 발하게 된다. 그 다음에 하드웨어 자원 디스패처(dispatcher)는 다음의 기능의 루틴을 수행한다.
。인터럽트 처리기(412)에 현재 가상 인터럽트를 저장되어 있으면, 인터럽트 처리기(412)는 가상 인터럽트들을 보조 운영체제로 전달한다.
。하드웨어 자원 디스패처(dispatcher) 운영체제 스케줄러(schedular)(410)는 작업을 수행할 해당 보조 운영체제(202)를 선택한다. 운영체제 스위칭기(408)는 핵심 운영체제 문맥 저장부(706)에 있는 현재 문맥(전형적으로는 프로세서 MMU와 상태 레지스터, 명령과 스택 포인터들)을 저장한다. 그리고 나서 스위칭기는 저장된 해당 보조 운영체제의 작업 수행 문맥(708)을 찾아내어 관련 레지스터상에 기록한다.
。해당 보조 운영체제에 대한 가상 인터럽트가 있는 경우는, 인터럽트 처리기(412)가 그 보조 운영체제의 유관 인터럽트 처리 루틴(ISR, 710)을 호출하는데, 이 루틴은 인터럽트를 서비스하고, 완료시에는 그 보조 운영체제의 스레드(712) 작업 수행의 최종 상태로 복귀한다.
인터럽트 처리기(412)가 현재 아무 pending(미결) 인터럽트를 가지지 않은 경우에, 하드웨어 자원 디스패처(dispatcher) 운영체제 스위칭기(408)는 보조 운영체제로 하여금 복원된 운영체제 문맥 내에 저장된 프로그램 카운터 값(program counter value)를 사용하여 인터럽트 직전 상태, 이 경우는 해당 스레드(712)부터 작업 수행을 재개하도록 한다.
따라서 핵심 운영체제(201)가 어떤 기능을 수행한 뒤 (그 자신의 서비스나 응용 프로그램를 서비스하거나, 또는 다른 운영체제에 대한 인터럽트를 서비스한 뒤), 하드웨어 자원 디스패처(dispatcher)는 스케줄러(schedular)(410)가 정하는 바에 따라 다음 보조 운영체제(202)로 제어 기능을 넘긴다.
인터럽트시 보조에서 핵심 운영체제로의 스위치
도 8을 참조하여, 보조 운영체제에서 핵심 운영체제로의 스위칭 과정을 개시한다. 이 경우 시스템은 핵심 운영체제(202)에서 실행되는 응용 프로그램(208a)의 스레드(712) 작업을 수행하고 있다.
하드웨어 인터럽트가 일어나면, 하드웨어 자원 디스패처(dispatcher)는 운영체제 스위칭기를 작동시켜 문맥 저장부(708)에 해당 보조 운영체제 문맥을 저장한다. 다음에 하드웨어 자원 디스패처(dispatcher)는 문맥 저장부(706)로부터 상태 변수값을 복원하여 주 운영체제(201)로 스위칭하고, 주운영체제(201)의 인터럽트 서비스 루틴을 호출한다. 인터럽트 서비스를 마친 뒤, 주운영체제(201)의 스케줄러(schedular)는 제어 기능을 인터럽트 서비스 루틴(704)으로부터 기존에 수행되고 있던 스레드(704)(혹은 수행될 스레드) 아무나로 넘기게 된다.
인터럽트 서비스 루틴과 모든 스레드를 처리한 뒤, 주운영체제(201)는 제어 기능을 하드웨어 자원 디스패처(dispatcher)로 넘기고, 하드웨어 자원 디스패처(dispatcher)는 도 7에서 논의한 방식으로 주운영체제(201)로부터(문맥 저장부(706)에 상태 변수를 저장) 선택된 보조 운영체제(202)(문맥 저장부(708)로부터 상태 변수를 찾아냄)로 스위칭한다.
운영체제간 통신-가상 버스(418)
가상 버스 루틴은 각 운영체제의 가상 버스 드라이버와 협력한다. 가상 버스 루틴은 compact PCI(cPCI) 백플레인(backplane)에 플러깅(plugging)된 cPCI 보드와 유사한, 운영체제 사이를 연결하는 물리적 버스를 에뮬레이트 한다. 각 운영체제는 이 가상 버스의 가상 버스 브리지 장치에 대한 드라이버 루틴을 제공받아, 운영체제와 그 응용 프로그램이 원시(raw) 데이터 전송으로부터 완전한 IP 프로토콜 스택에 이르기까지 원하는 어떠한 프로토콜과도 통신할 수 있게 하여 준다.
하드웨어 자원 디스패처(dispatcher) 가상 버스는 위에서 이미 설명한 공유 메모리와 시스템 교차 인터럽트 원리에 그 바탕을 둔다. 자세히는 가상 버스 루틴(418)이 공유된 장치의 가상 버스 브리지를 규정하는 C5 buscom DDI:syscom을 에뮬레이트 하는데, 이는 가상 버스를 통한 메모리 내보내기(공유)과 다른 운영체제를 향하는 교차 인터럽트의 발생을 가능하게 한다.
각 보조 운영체제의 각 가상 버스 드라이버는 스타트업 타임(startup time)이 되면 하드웨어 자원 디스패처(dispatcher) 하드웨어 저장소에 그러한 가상 버스 브리지를 만든다. 이렇게 함으로써 드라이버는 자신의 개인 메모리의 한 영역을 내보내기(공유)하고, 자신의 호스트 시스템 내에서 인터럽트를 제기하는 수단을 제공한다.
따라서 제1운영체제의 가상 버스 드라이버는
。보조 운영체제의 동료 가상 드라이버가 내보내기하는 메모리에 기록하고, 그 다음에
。그 보조 운영체제의 동료 버스 드라이버에게 데이터 사용이 가능하다고 알리는 교차 인터럽트를 일으켜서 보조 운영체제로 데이터를 전송한다.
반대 방향(들어오는 방향)으로는 가상 버스 드라이버에 그러한 데이터가 자신의 고유한 내보내기 메모리 영역에 저장되었다는 교차 인터럽트가 수신되면, 가상 버스 드라이브는 들어오는 데이터 업스트림(upstream, 그 대상 응용 프로그램이나 루틴의 사용을 위한)을 전파한다.
도 9a를 참조할 때, 동일한 운영체제(202)에서 실행 중인 다른 응용 프로그램(208b)과 통신할 응용 프로그램(208a)은 그 운영체제를 통하여 통신이 가능하다. 한 운영체제(201)에서 실행 중인 응용 프로그램(207b)이 다른 운영체제(202)에서 실행 중인 다른 응용 프로그램(208b)과 통신할 경우는, 자신의 운영체제의 API를 사용하여 그 가상 버스에 데이터를 기록하여 통신할 수 있는데, 그 운영체제는 가상 버스 드라이버 루틴을 사용하여 데이터를 다른 운영체제(202)로 넘기며, 그 다 른 운영체제(202)는 자신의 가상 버스 드라이버로부터 응용 프로그램(208b)에 데이터를 전파한다.
도 9b를 참조할 때, 이 배치를 제1운영체제와 보조 운영체제가 각각 다른 컴퓨터(101,102)에서 실행 중인 환경으로 옮기는 데 필요한 변경은 조금뿐이다. 다만 운영체제들이 가상 버스 드라이버 대신 실제 버스(103)용 드라이버를 사용하도록 운영체제가 사용하는 드라이버를 바꿔 주어야 할 뿐이다. 그러므로 시스템은 자신이 작동하는 하드웨어와 더욱 독립적으로 된다.
하드웨어 자원 디스패처(dispatcher) 가상 버스를 통하는 통신은 응용 프로그램도 이용 가능하지만, 운영체제 커널이 여러 개의 운영체제에 배분되는 서비스를 구현하는 것을 서로 도울 수 있도록 운영체제 커널에 의하여 내부적으로도 이용 가능하다. 이러한 "스마트"형 배분 서비스에는 운영체제 핫 재시작(앞서 설명)에 쓰이는 소프트웨어 감시 또는 배분되는 네트워크 프로토콜 스택이 속한다.
디버깅
모범 실시예에서 하드웨어 자원 디스패처(dispatcher)는 디버그 에이전트(agent)로서 작용하는 제2의 작동 모드가 있다. 본 실시예에 따르면 제2 모드에서 하드웨어 자원 디스패처(dispatcher)는 직렬 통신선을 통하여 다른 컴퓨터("호스트" 머신)에서 실행 중인 디버깅 소프트웨어와 통신할 수 있다. 이러한 디버깅 툴은 높은 수준의 그래픽 사용자 인터페이스(GUI)를 제공하여 하드웨어 자원 디스패처(dispatcher)를 원격 조정한다. 하드웨어 자원 디스패처(dispatcher)의 가상화 예외(exception) 메카니즘은 규정된 예외(exception)를 인터셉트하기 위하여 사용된다. 사용자는 그 다음 하드웨어 자원 디스패처(dispatcher)가 프로세서 예외(exception)시 어떻게 거동(behaviour)하는지를 설정하고 제어할 수 있으며 코드 에러나 여타 시스템 에러 또는 문제들을 진단할 수 있도록 머신과 시스템 상태 변수를 표시하게 할 수 있다.
사용자는 하나 또는 여러 개의 그러한 프로세서 예외(exception)를 운영체제가 하드웨어 자원 디스패처(dispatcher)를 트랩 호출하는 바탕으로 선택할 수 있다. 선택된 예외(exception)에 기초하여 작업 수행 도중 예외(exception) 또는 각 예외가 일어나면 운영체제는 중단되고, 하드웨어 자원 디스패처(dispatcher)에 대한 트랩 호출을 수행하는데, 하드웨어 자원 디스패처(dispatcher)는 다시 현 문맥을 저장하고 호스트 머신의 디커깅 툴과 상호작용할 수 있게끔 작용한다. 사용자는 이제 상태 변수들의 현재 상태(스택 포인터, 프로그램과 주소 카운터 등) 및/또는 선택한 메모리 블록의 내용을 표시하게 할 수 있다. 사용자는 어떤 특정 유형의 예외(exception)들이 디버깅 대상인 특정 운영체제에 트랩(trap)되거나, 발생하는 즉시 아무 운영체제에라도 트랩되도록 할지를 명시할 수 있다. 이에 대응하여 트랩 호출은 모든 운영체제나 아니면 단 한 운영체제에만 구현된다. 사용자는 어느 특정 유형의 예외(exception)를 작업 수행이 재개될 때 운영체제에 정상적으로 전달할지 또는 무시할지를 명시할 수도 있다.
하드웨어 자원 디스패처(dispatcher)는 자신의 고유한 환경에서 작동하므로, 운영체제의 버그를 제거하는 데에 있어서 그 운영체제가 직접 하는 경우보다 훨씬 더 많이 제거할 수 있다. 디버깅 장치 역할을 하는 하드웨어 자원 디스패처(dispatcher)와 디버깅 대상인 운영체제 사이에는 어떠한 코드도 공유하지 않는다는 점이 중요하다. 이 때문에 예를 들어 예외(exception) 벡터 또는 인터럽트 서비스 루틴과 같은 커널 저수준(low level) 코드까지 디버그가 가능하다.
본 실시예에 따른 전체(호스트/타겟) 디버깅 구조(architecture)의 다른 측면들은 Chorus와 C5의 디버깅 시스템의 경우와 비슷하며, 이들에 대해서는 http://www.jaluna.com/doc/c5/html/DebugGuide/book1.html에서 얻을 수 있는 Jaluna社 발간 "C5 1.0 Debugging Guide"에 기재되어 있다.
보안 구조( secure architecture )
위에 설명한 본 발명의 실시예가 보안 구조를 위한 견고한 바탕이 된다는 것는 분명할 것이다. 이것은 사용자가 전형적으로 비보안성 응용 프로그램을 실행하는 보조 운영체제는 명시된 시스템 자원으로부터 절연되어 있고, 그 자원에 대한 접근은 오로지 하드웨어 자원 디스패처(dispatcher)(그리고 주운영체제의 드라이버)를 통하여서만 이루어지기 때문이다. 따라서 주운영체제에서 암호화/암호 해제, 암호 처리된 파일에 대한 접근 허가, 패스워드와 다른 접근 정보의 관리·저장·공급, 저작권 관련 자료의 접근과 재생에 대한 관리·장부 작성 등을 예로 들 수 있는 보안성 응용 프로그램을 실행할 수 있다. 보조 운영체제에서 실행 중인 응용 프로그램은 그 운영체제에 할당되지 않은 시스템 자원에 접근할 수 없으며, 또 운영체제들이 서로 다른 메모리 문맥(즉 서로 다른 공간에 대한 서로 다른 주소 지정 포인터)에서 실행 중인 때에는 보조 운영체제에서 실행 중인 응용 프로그램이 주운영체제에서 작동 중인 다른 응용 프로그램을 방해하여 그 작동의 보안성을 취약하게 하는 일은 할 수 없다.
Intel 구조 실시예 특징( Intel Architecture embodiment features )
이하, 하드웨어 자원 디스패처(dispatcher)는 (비제한 센스(non-limiting sense) 안에서) 나노커널(nanokernel)로서 설명된다. 본 섹션에서는 나노커널(nanokernel) 이행의 IA-32 Intel 특유의 관점, 특히, 나노커널(nanokernel) 환경의 초석인 나노커널(nanokernel) 행정부(executive)로 초점을 맞춘다.
이는 IA-32 Intel 프로세서 구조가 이 운영체제들을 통해 메모리 관리 장치(MMU, memory management unit)와 마찬가지로 중앙 처리 장치(CPU)와 부동 소수점 처리 장치(FPU, cfloating-point processor units)를 동시에 공유하는 다중의 독립의 운영체제를 작동할 수 있는 나노커널(nanokernel) 행정부(executive)를 이행하기 위하여 어떻게 이용되는지를 설명한다.
이는 또한, 나노커널(nanokernel) 행정부(executive)가 어떻게 하드웨어 인터럽트를 다루는지 설명한다. 특히, 주운영체제를 향한 하드웨어 인터럽트와 보조 운영체제에 제공된 소르트웨어 인터럽트 메커니즘을 인터셉트하고 전달하기 위한 메커니즘을 설명한다.
나노커널(nanokernel)이 단일프로세서(uniprocessor) 컴퓨터에서 작동하고 있다고 가정한다는 것을 유의해야하며, 따라서 대칭형 멀티 프로세서(SMP, symmetrical multi-processor) 구조와 관련 있는 관점은 여기에서 언급되지 않는다.
Overview
가상 주소 공간( Virtual Address Spaces )
IA-32 Intel 구조에서 나노커널(nanokernel)은 항상 가상의 주소 공간에서 작동하는데, 이를 달리 표현하지면, MMU는 항상 enabled(허용)되어 있다는 것이다. 반면에, 나노커널(nanokernel) 코드가 수행되고 있는 메모리 문맥은 시간에 따라 변화할 수도 있다
설명에서 메모리 문맥 용어는 CR3 레지스터에 의해 명기된 루트 디렉토리 테이블이 있는 IA-32 주소 번역 트리(tree)를 가리킨다.
일반적으로, 사용자 모드를 지원하는 운영체제는 개인 사용자 가상 주소 공간을 처리할 수 있게끔 다중 메모리 문맥(사용자 process당 하나)을 만든다. 커널은 사용자 process로부터 다른 것으로 바꿀 때마다 메모리 문맥을 변경한다. 다른 한 편으로는, 운영체제 커널은 또한, 사용자 주소 공간과 함께 전체 메모리 문맥으로 반복되는 유일한 관리자 주소 공간을 처리한다. 사용자와 관리자 가상 주소는 IA-32 Intel 구조에 절대 겹치지 않는다.
관리자 주소 공간 매핑은 정적이거나 동적일 수 있다. 정적 매핑은 시스템 초기화 시간에 만들어지고, 물리적 enabled(허용) 메모리를 (전체적으로 또는 부분적으로) 전형적으로 나타낸다. 이 같은 매핑은 1 대 1 또는 커널 가상(KV) 매핑이라 불린다. 특히, KV 매핑은 커널 코드, 데이터 그리고 bss 섹션을 담당한다. 동적 매핑은 동적으로 적재된 커널 모듈이나 동적으로 할당된 (비연속적인) 메모리 덩어리에 접근하기 위한 수단으로 실행 시간 중에 만들어진다.
메모리 문맥의 세 종류는 나노커널(nanokernel) 환경에서 주 메모리 문맥, 보조 메모리 문맥, 그리고 나노커널 메모리 문맥으로 구별된다.
주 메모리 문맥은 현재 주 커널로 사용된 메모리 문맥이다. 위에서 언급한 바와 같이, 주 운영체제가 사용자 주소 공간을 지원하는 경우, 주 커널로 사용된 다중 메모리 문맥이 있을 수 있지만, 관리자 주소 공간은 모든 문맥에서 동일하다는 것을 주목해야 한다. 나노커널(nanokernel)이 사용자 매핑에 대해 관여하지 않기 때문에, 주 메모리 문맥은 나노커널(nanokernel) 투시도(perspective)와 다르고 정적으로 이루어지며, 동적 관리자 매핑은 주 커널에 의해 확립된다.
보조 메모리 문맥은 보조 커널로 사용된 메모리 문맥이다. 한번 더 제2운영체제가 사용자 주소 공간을 지원하는 경우, 보조 커널로 사용된 다중 메모리 문맥이 있을 수 있지만, 관리자 주소 공간은 여전히 모든 문맥에서 동일하다. 나노커널(nanokernel)은 단지 보조 커널에 의해 확립된 정적 KV 매핑만을 감지하므로, 보조 메모리 문맥은 나노커널(nanokernel) 투시도(주어진 보조 커널을 위한)와 다르고, 그것은 1 대 1 매핑으로 이루어진다. 나노커널(nanokernel)이 동적 KV 매핑을 통해 나노커널(nanokernel)로 사용된 보조 커널 데이터로 접근할 수 있음을 요구한다는 사실을 주지하는 것이 중요하다. 그런 데이터 구조는 보조 커널에 대한 나노커널(nanokernel) 인터페이스를 설명하는 이후의 섹션에 나열되어 있다.
나노커널(nanokernel) 메모리 문맥은 나노커널(nanokernel) 자신에 의하여 구축된 것이다. 이 문맥은 모든 보조 커널은 물론 주 커널에 의해 확립된 KV 매핑 전체를 재생산한다. 그러한 메모리 문맥을 만들기 위하여서, 나노커널(nanokernel)은 모든 KV 매핑의 호환성을 요구한다. 두 KV 매핑은 그들이 겹쳐지지 않거나 동일한 경우에 한해서 호환성이 있다.
동일한 다중 보조 커널을 실행할 때, 그들의 KV 매핑은 자연적으로 동일하고, 그러므로 호환성이 있음을 주지해야 한다. 그러나 주 운영체제가 보조 운영체제와 다를 때 문제가 발생할 수도 있다. 이 경우, KV 매핑의 호환성을 획득하기 위하여 시스템 중 하나를 수정하는 일이 필요할지도 모른다.
예를 들어, 나노커널(nanokernel) 콘솔에 I/O 동작을 수행하기 위하여 보조 커널이 나노커널(nanokernel)에 의해 처리되는 인터럽트, 트랩 또는 예외(exception) 이벤트로서 접수될 때, 나노커널(nanokernel) 코드를 실행하는데 나노커널(nanokernel) 메모리 문맥이 주로 이용된다. 나노커널(nanokernel) 메모리 문맥은 또한, 보조 실행 환경을 주 실행 환경으로, 또는 그 반대로 스위칭하도록 enabled(허용)하는 중간의 주소 공간으로도 사용된다.
나노커널(nanokernel) 이진수는 주 KV 매핑에서 발생하고, 나노커널(nanokernel) 코드는 주 메모리 문맥이나 나노커널(nanokernel) 메모리 문맥 중 어 느 한쪽에서 실행된다. 다시 말해, 나노커널(nanokernel) 코드는 주 커널로 규정된 1 대 1 매핑에서 실행된다. 나노커널(nanokernel)이 주 커널을 접수할 때, 나노커널(nanokernel) 코드는 주 메모리 문맥에서 실행된다. 나노커널(nanokernel)이 보조 커널을 접수할 때, 나노커널(nanokernel) 코드는 주 KV 매핑을 반복하는 나노커널(nanokernel) 문맥에서 실행된다. 주 커널에 의해 호출된 나노커널(nanokernel) 동작은 주 메모리 문맥에서 실행되므로 주 관리자 주소 공간은 직접적으로 접근될 수 있기 때문에, 일반적으로 나노커널(nanokernel)로 사용된 주 데이터에는 어떠한 제한도 없음을 주지하여야 한다. 한편, 보조 커널로/로부터(to/from) 스위칭하는 동안, 나노커널(nanokernel)은 정적 KV 매핑을 통해 나노커널(nanokernel)로 사용된 다소의 주 커널 데이터로 접근할 수 있음을 요구한다. 그런 데이터 구조는 주 커널에 대한 나노커널(nanokernel) 인터페이스를 설명하는 이후의 섹션에 나열되어 있다.
도 10은 주, 보조, 그리고 나노커널(nanokernel) 가상 주소 공간의 실시예를 보여준다.
본 실시예에서, 물리적 메모리의 크기는 128 megabyte이다. 주 커널은(C5 마이크로커널과 같이) 0에서부터 시작하는 자명한 1 대 1 (KV) 매핑을 이용하고, 보조 커널은 (리눅스 커널과 같이) 0xc0000000에서부터 시작하는 시프트(shift)된 1 대 1 (KV) 매핑을 이용한다. 이러한 KV 매핑들은 호환성이 있고 나노커널(nanokernel) 주소 공간은 상기 두 개의 1 대 1 매핑을 두 번 재생산하는 물리적 메모리를 나타낸다.
도 11은 메모리 문맥이 어떻게 제시간에 스위칭되는지를 보여준다. 최초에, 보조 운영체제는 보조 메모리 문맥에서 동작하고 있다. t0의 시간에, 현재 보조 커널은 나노커널(nanokernel) 콘솔로 문자열을 출력하기 위하여서 나노커널(nanokernel)에 트랩다. 이 트랩은 현재 메모리 문맥을 나노커널(nanokernel) 메모리 문맥으로 스위칭한다. [t0, t1] 기간 동안, ( 나노커널(nanokernel) 메모리 문맥에서 작동하는) 나노커널(nanokernel)은 나노커널(nanokernel) 콘솔로 문자열을 출력한다. t1의 시간에, 나노커널(nanokernel)은 보조 메모리 문맥으로 되돌아가는 보조 커널로 돌아간다. t2의 시간에, 보조 운영체제를 동작하는 동안 인터럽트가 발생한다. 인터럽트는 현재 메모리 문맥을 나노커널(nanokernel) 메모리 문맥으로 스위칭하고, 나노커널(nanokernel) 인터럽트 처리기를 불러낸다. 인터럽트를 주 커널로 전송하기 위하여서, t3의 시간에 나노커널(nanokernel)은 나노커널(nanokernel) 메모리 문맥을 주 메모리 문맥으로 스위칭하고, 주 인터럽트 처리기를 불러낸다. t4의 시간에 인터럽트 요구를 처리하는 동안, 주 커널은 나노커널(nanokernel) 콘솔에 메세지를 출력하기 위하여 나노커널(nanokernel) 기록 방법을 불러낸다. 이는 메모리 문맥을 스위칭하지 않으며, 기록 동작이 주 메모리 문맥에서 전적으로 실행되는 간단한 간접적인 호출임을 유의하여야 한다.
t6 시간에 인터럽트 요구를 처리할 때까지, 나노커널(nanokernel)은 t5의 시간에 기록 방법에서 주 커널로 돌아간다. 이 순간, 주 커널은 인터럽트 처리기에서 돌아오고, 나노커널(nanokernel)은 인터셉트 된 보조 운영체제로 되돌아가 그것의 실행을 지속한다. 그런 스위칭은 주 메모리 문맥에서 시작하고, 중간의 나노커널 (nanokernel) 문맥을 통과하면서, 결국 t7의 시간에 보조 메모리 문맥에서 끝이난다.
나노커널 불러내기과 접수 ( Nanokernel Invocation and Preemption )
나노커널(nanokernel)은 함수 호출/트랩을 통해 명시적으로 또는 인터럽트/예외 처리기를 통해 암시적으로 불러내진다. 전자의 경우에, 우리는 운영체제 커널이 나노커널(nanokernel)을 불러낸다고 말한다. 후자의 경우에, 우리는 나노커널(nanokernel)이 운영체제를 접수한다고 말한다. 나노커널(nanokernel)은 항상 관리자 주소 공간에서 실행하는 특권이 있는 코드로부터 불러내진다는 점을 강조하는 것이 중요하다. 반면, 나노커널(nanokernel)은 커널 제어 하에서 작동하는 사용자 프로세스와 마찬가지로 커널 그 자체로서 접수할 수 있다.
일단 시스템이 부팅되면, 우선 나노커널(nanokernel)이 활성화되고 주 커널과 보조 커널의 실행을 시작한다. 일단 초기화 단계가 완료되면, 나노커널(nanokernel)은 수동적인 역할을 수행한다. 이는 나노커널(nanokernel)에서 실행된 코드가 (호출이나 트랩에 의해) 나노커널(nanokernel)을 명시적으로 호출하는 주 커널 및 보조 커널에 의하여, 또는 외부적으로 생성되는 동기(즉, 예외(exception))와 비동기(즉, 인터럽트) 이벤트에 의하여 가동된다는 뜻이다.
IA-32 Intel 구조에서, 나노커널(nanokernel)의 과 접수를 위하여 사용된 메커니즘은 주 운영체제와 보조 운영체제를 위하여 사용된 것과 다르다. 실행 환경의 면에서, 나노커널(nanokernel)은 주 커널과 매우 밀접하다. 그것은 동일한 메모 리 문맥을 사용하고, 간혹, 동일한 관리자 스택을 사용한다. 그래서, 나노커널(nanokernel)은 주 커널과 대략적으로 동일한 가용성을 가지고 있다. 다른 한편으로는, 보조 커널의 오작동을 방어하기 위한 몇몇의 보호를 제공하기 위하여, 상기 보조 운영체제와 나노커널(nanokernel) 사이에는 장벽이 있다. 그러나 그러한 보호는 절대적이지 않으며, 보조 커널은 나노커널(nanokernel) 뿐 아니라 주 커널을 파손시킬 수 있다는 것을 주지하여야 한다.
주 불러내기 ( Primary Invocation )
주 커널은 간단하고 간접적인 불러내기에 의해 나노커널(nanokernel)을 호출한다. 메모리 문맥은 불러내기에 의해 스위칭되지 않는다.
주 접수 ( Primary Preemption )
나노커널(nanokernel)은 인터럽트 게이트(gate)를 통해 주 운영체제를 접수한다. 메모리 문맥은 접수에 의해 스위칭되지 않고, 고유 주 관리자 스택은 접수를 처리하는데 이용된다.
나노커널(nanokernel)은 오직 드문 경우에만 주 운영체제를 접수한다. 그 중 하나는 본 명세서에서 앞으로 설명되는 바와 같이 느린 방식(lazy fashion)에 의해 커널들 사이에서 분배된 FPU를 처리하기 위하여 나노커널(nanokernel)로 사용되는 예외(exception) (#NM)를 장치가 사용하지 못하는 경우이다.
보조 불러내기 ( Secondary Invocation )
하나의 보조 커널은 트랩에 의해 나노커널(nanokernel)을 호출한다. 나노커널(nanokernel)은 나노커널(nanokernel) 메모리 문맥과 스위칭하는 작업 게이트(gate)에 의해 위와 같은 트랩을 인터셉트 하고, 상기 트랩 작업 실행을 시작한다.
보조 접수( Secondary Preemption )
보조 운영체제의 나노커널(nanokernel) 접수는 불러내기 메커니즘과 유사하고 작업 게이트(gate)에 기초하고 있다. 보조 시스템이 인터럽트나 예외(exception)에 의해 접수될 때, 그에 상응하는 작업 게이트(gate)는 나노커널(nanokernel) 메모리 문맥과 스위칭하고 그에 상응하는 나노커널(nanokernel) 작업의 예외(exception)를 시작한다.
커널 문맥( Kernel Context )
나노커널(nanokernel) 데이터는 범용 데이터와 커널-당 데이터의 두 개의 카테고리로 분할될 수 있다. 범용 데이터는 커널-당 데이터가 주어진 주 커널이나 보조 커널과 관련된 상태를 유지하는 동안 나노커널(nanokernel) 상태 (예를 들어, 나노커널(nanokernel) 메모리 문맥)를 유지한다.
커널 문맥은 보이는 부분과 숨겨진 부분의 두 부분으로 구성된다. 보이는 부분은 공용이고 나노커널(nanokernel) 인터페이스에 가담한다. 커널 문맥의 이 부분은 앞으로 나노커널(nanokernel) 인터페이스와 관련된 섹션에서 좀 더 자세히 설 명할 것이다. 숨겨진 부분은 커널에 보이지 않고 나노커널(nanokernel) 행정부(executive)에 의해 내부적으로 사용된다.
나노커널 행정부( executive ) 인터페이스( Nanokernel Executive Interface )
본 장(chapter)에서는 주 커널과 보조 커널에 전파된 나노커널(nanokernel) 행정부(executive) 인터페이스에 대해 설명한다. 그러한 인터페이스는 나노커널(nanokernel) 방법과 마찬가지로 커널과 나노커널(nanokernel) (즉, 보이는 커널 문맥) 사이에 공유된 데이터에 있다. 나노커널(nanokernel) 인터페이스는 커널 역할 특성이고, (엄밀히 말해) 주 커널과 보조 커널을 위하여 다르다는 것을 유의하여야 한다. 반면, 커널 역할로부터 독립적으로 설명할 수 있는 이 둘의 인터페이스 사이에는 아주 중요한 교차점이 있다.
보이는 커널 문맥 ( Visible Kernel Context )
도 12는 커널 문맥의 보이는 부분을 나타낸다.
(보조 뿐 아니라 주) 모든 커널 문맥은 순환 리스트에 연결된다. next 필드는 그러한 리스트 안에서 다음 커널 문맥을 참조한다. 커널 문맥의 보이는 부분 안에서, 모든 참조는 물리적인 주소를 통해 만들어진다는 것을 주목하라. 커널은 참조된 객체에 접근하기 위하여 그러한 물리적 주소를 (KV 매핑으로부터) 가상 주소로 변환해야 한다. 도 12는 단지 주와 부의 두 개의 커널로 이루어지는 구성을 보여준다. 주 문맥은 보조 문맥을 가리키며, 그 다음, 보조 문맥은 다시 주 문맥을 가리킨다.
pending (미결) VEXenabled (허용) VEX 필드는 가상 예외(exception)의 현재 상태를 반영한다. 주 커널 예외(exception)는 나노커널(nanokernel)에 의해 가상화된 것이 아니므로, 이 필드들은 주 문맥에 불필요하다는 것을 유의하여야 한다. 가상화된 예외(exception) 메커니즘은 보조 커널 예외(exception) 모델과 함께 앞으로 더욱 상세히 설명될 것이다.
boot info(부트 정보) 필드는 BIOS에 의해 주어진 부트 매개변수를 가리킨다. 이 필드는 읽기 전용이다.
그러한 데이터 구조는 커널 특성이므로, 또한 커널 문맥에 위치한다는 사실에 유의하여야 한다. 다른 필드 사이에서, 부트 매개변수 구조는 부트 시간 매개변수를 명시하는 부트 명령어 라인을 가리킨다. 그러한 매개변수는 부트 로더 (예를 들어, GRUB 부트 로더)에 주어지거나, 또는 나노커널(nanokernel) 환경을 통해 전달된다. 명령어 라인은 커널 특성이고 또한 커널 문맥에 위치한다. 나노커널(nanokernel)은 대응하는 커널과 관계있는 매개변수만을 포함하는 커널 특성 명령어 라인을 만들기 위하여 최초의 명령어 라인을 문법적으로 분석한다.
RAM info ( RAM 정보) 필드는 RAM 기술 테이블을 가리킨다. 이 테이블은 읽기 전용이다. RAM 기술 테이블은 모든 커널에 의해 공유된 범용 데이터 구조이다. RAM 소스가 커널을 통해 어떻게 할당됐는지를 보여준다.
dev info ( dev 정보) 필드는 나노커널(nanokernel)에 의해 추출된 가상의 장치 리스트를 가리킨다. 이 필드는 보조 커널을 위하여서는 읽기 전용이고 주 커널 을 위하여서는 읽고 쓰기용이다. 장치 리스트는 범용이고 모든 커널에 의해 공유된다. 리스트에 있는 가상 장치 각각은 나노커널(nanokernel)에 의해 명시된 데이터 구조로 나타내어진다. 일반적으로 나노커널(nanokernel)에 의해 정의된 규칙을 사용한 주 동료 드라이버와 보조 동료 드라이버 양쪽 모두 이 데이터 구조로 접근한다. 보조 종료 드라이버가 실재 장치 대신 가상 장치를 이용해 클라이언트 역할을 수행할 동안, 주 동료 드라이버는 가상 장치를 지원하는 서버 역할을 수행한다. 이 리스트는 오직 주 커널에 의해 생성된다. (그리고 변경된다.) 보조 커널은 이 리스트를 단지 읽을 수만 있도록 enabled(허용)한다.
pending XIRQ (pending(미결) XIRQ ) 필드는 pending(미결)된 교차 인터셉트를 명시한다. 이 필드는 나노커널(nanokernel) 그 자체만으로 사용되지 않는다. 교차 인터럽트 스위칭에서 주 커널과 보조 커널을 돕기 위하여 문맥 구조에 의해 호스트 된다. 교차 인터럽트 배달 전용의 예외(exception)는 오직 한 개이다. pending XIRQ (pending(미결) XIRQ ) 필드는 32(교차 인터럽트 소스당 한 개의 비트)까지 교차 인터럽트의 수를 확장하는 것을 enabled(허용)한다. 교차 인터럽트 비트는 소스 커널 (즉, 인터럽트를 가로질러 송신하는 커널)에 의해 설정되고, 목적 커널 (즉, 교차 인터럽트를 수신하는 커널) 에 의해 재설정된다.
ID 필드는 유일한 커널 식별자를 포함한다. 이 필드는 읽기 전용이다. 식별자 0은 나노커널(nanokernel) 그 자체에 할당되고, 1은 주 커널에 할당된다. 커널 식별자는 나노커널(nanokernel) 인터페이스에 있는 나노커널(nanokernel)을 가리킨다. 예를 들어, 커널 식별자는 주어진 커널 (예를 들어, RAM 기술 테이블에 있는 메모리 덩어리)로 할당된 자원에 부가하도록 사용된다.
running (실행) 필드는 실행 또는 정지의 커널 상태를 나타내는 플래그(flag)이다. 이 필드는 읽기 전용이다. 나노커널(nanokernel)은 커널을 개시하기 전에 이 플래그를 설정하고, 커널이 한 번 정지하면 플래그를 지운다. 커널이 재시작될 때, running (실행) 플래그는 처음에는 지워지고, 곧 설정된다. 어떤 커널도 커널 문맥의 순환 리스트를 읽을 수 있고, 실행 동료 커널 전체를 찾아내기 위하여 running (실행) 플래그를 분석할 수 있다. running(실행) 플래그는 언제나 주 커널을 위하여 설정된다는 것을 유의하여야 한다.
보이는 커널 문맥의 마지막 부분은 역할 특성이다.
주 문맥은 나노커널(nanokernel) 인터페이스 방법의 주소를 명시한다. 주 커널은 간접적인 함수 호출을 통해 나노커널(nanokernel)을 불러내기 위하여 이 주소를 사용한다. 방법 주소는 나노커널(nanokernel)에 의해 공급되고 주 커널에 의해 변경되면 안된다. 나노커널(nanokernel) 인터페이스 방법은 다음 섹션에서 더욱 자세히 설명한다.
보조 커널은 나노커널(nanokernel)을 호출하기 위하여 간접적인 호출보다 트랩 메커니즘을 사용한다. 따라서, 나노커널(nanokernel) 인터페이스 방법의 주소는 보조 문맥에 존재하지 않는다. 대신, 보조 문맥은 CR0 레지스터의 TS 비트 상태를 유지하는 secondary TS 비트(보조 TS 비트)를 가진다. 그러한 TS 비트의 소프트웨어 이미지는 앞으로 더욱 상세히 설명될 느린 방법에 따라 FPU 자원을 관리하기 위하여 보조 커널로서 사용된다.
나노커널 방법( Nanokernel Methods )
나노커널(nanokernel)은 콘솔 I/O 작동과 행정부(executive) 작동의 두 그룹의 방법을 제공한다. 콘솔 I/O 그룹은 커널이 나노커널(nanokernel) 콘솔 직렬 회선으로/으로부터(to/from) 특성을 송신/수신하도록 enabled(허용)한다. 본 명세서는 특히 더욱 또는 덜 범용인 콘솔 I/O 방법에 초점을 맞추기보다는 IA-32 Intel 구조 특성인 행정부(executive) 방법에 초점을 맞춘다.
기본적으로, 나노커널(nanokernel) 환경은 나노커널(nanokernel) 방법으로 몇몇의 IA-32 Intel 프로세서 명령을 대신한다. 그러한 대용 명령은 일반적으로 몇몇의 IA-32 Intel 프로세서 레지스터를 적재하거나 저장한다:
。범용 디스크립터(descriptor) 테이블 레지스터 (GDTR, Global 디스크립터(descriptor) Table Register)
。인터럽트 디스크립터(descriptor) 테이블 레지스터 (IDTR, Interrupt Descriptor Table Register)
。작업 레지스터 (TR, Task Register)
적재/저장 GDT 레지스터 ( LGDT / SGDT , Load / Store GDT Register )
나노커널(nanokernel) 환경에서 IA-32 LGDT/SGDT 명령에 의해 GDT 레지스터로/로부터 직접적으로 적재/저장하는 대신, 그와 같이 하기 위하여 커널은 LGDT/SGDT 나노커널(nanokernel) 방법을 불러내야 한다. 이 방법들은 주 커널을 위 한 간접적인 호출과 보조 커널을 위한 트랩을 제외한, 주 커널 그리고 보조 커널과 유사하다.
프로세서 명령과 유사하게, LGDT/SGDT 나노커널(nanokernel) 방법은 고유 테이블 기초로 한 주소 (하나의 가상 주소)와 고유 테이블 한계 (byte로 표현된 테이블의 크기)를 포함한 6-byte 메모리 위치를 나타내는 오직 매개변수만을 취한다. 고유 GDT가 언제나 FV 매핑 ( 주 커널 조차) 안에 위치해야 한다는 것을 강조하는 것이 중요하다.
나노커널(nanokernel)은 커널-당 범용 디스크립터(descriptor) 테이블을 관리한다. 이 (실재) 테이블은 도 13에 나타난 커널 문맥의 숨겨진 부분에 존재한다. 나노커널(nanokernel)은 실재 GDT와 함께, GDT 방법에 의해 나노커널(nanokernel)에 주어진 고유의 GDT에 포인터를 유지시킨다.
나노커널(nanokernel)은 세그먼트 디스크립터(descriptor)를 복사함으로써 고유 GDT로부터 실재 GDT로 초기화한다. 그러나 실재 GDT의 일부는 나노커널(nanokernel) 세그먼트를 위하여 남겨둔다는 것을 유의하여야 한다. 나노커널(nanokernel)은 고유 테이블과 실재 테이블 사이에서 매핑을 명시하는 문자열 비트를 처리한다. 실재 테이블에서 엔트리 각각을 위하여, 매핑은 나노커널(nanokernel) 세그먼트를 위하여 엔트리가 사용디는지 아니면 고유 테이블로부터 엔트리가 승계되는지를 명시하므로 그에 상응하는 커널 세그먼트의 복사를 포함한다. 나노커널(nanokernel) 세그먼트로 사용된 실재 엔트리는 LGDT 방법에 의해 갱신(update)되지 않는다.
나노커널(nanokernel) 세그먼트는 디폴트 크기가 256 엔트리인 실재 테이블의 말미에 위치한다. 커널을 나노커널(nanokernel) 구조로 이식할 때, 커널과 나노커널(nanokernel) 세그먼트 사이의 중복은 고유 테이블 내부에서 (그들을 테이블의 앞단으로 이동시킨다) 커널 세그먼트를 재-배치하거나, 상기의 실재 GDT를 증가시킴으로써 회피되어야 한다.
적재/저장 IDT 레지스터 ( LIDT / SIDT , Load / Store IDT Register )
나노커널(nanokernel) 환경에서 IA-32 LIDT/SIDT 명령에 의해 IDT 레지스터로/로부터 직접적으로 적재/저장하는 대신, 그와 같이 하기 위하여 커널은 LIDT/SIDT 나노커널(nanokernel) 방법을 불러내야 한다. 이 방법들은 주 커널을 위한 간접적인 호출과 보조 커널을 위한 트랩을 제외하면, 주 커널 그리고 보조 커널과 유사하다.
프로세서 명령과 유사하게, LIDT/SIDT 나노커널(nanokernel) 방법은 고유 테이블 기초로한 주소 (하나의 가상 주소)와 고유 테이블 한계 (byte로 표현된 테이블의 크기)를 포함한 6-byte 메모리 위치를 나타내는 오직 매개변수만을 취한다. 고유 IDT는 언제나 FV 매핑 ( 주 커널 조차) 안에 위치해야 한다는 것을 강조하는 것이 중요하다.
나노커널(nanokernel)은 커널-당 범용 디스크립터(descriptor) 테이블을 관리한다. 이 (실재) 테이블은 도 13에 나타난 커널 문맥의 숨겨진 부분에 존재한다. 나노커널(nanokernel)은 실재 IDT와 함께, IDT 방법에 의해 나노커널(nanokernel) 에 주어진 고유의 IDT에 포인터를 유지시킨다. 나노커널(nanokernel)은 게이트(gate) 디스크립터(descriptor)를 복사함으로써 고유 GDT로부터 실재 GDT로 초기화한다.
하나의 예외(exception)를 인터셉트하기 위하여 실재 테이블에서 나노커널(nanokernel)은 그만의 게이트(gate)를 인스톨(install)할 수 있음을 유의해라. 예를 들어, 나노커널(nanokernel)은 느린 방식(lazy fashion)에 따라 공유된 FPU를 관리하기 위하여 유용하지 않는 예외(exception) (#NM) 장치를 인터셉트한다. 따라서, GDT와 유사하게, 나노커널(nanokernel)은 고유 테이블과 실재 테이블 사이에서 매핑을 명시하는 문자열 비트를 처리한다.
실재 테이블에서 엔트리 각각을 위하여, 매핑은 나노커널(nanokernel) 게이트(gate)와 함께 엔트리가 인스톨 되는지, 아니면 고유 테이블로부터 엔트리가 승계되는지를 명시하므로, 그에 상응하는 커널 게이트(gate)의 복사를 포함한다. 나노커널(nanokernel) 게이트(gate)와 더불어 인스톨된 실재 엔트리는 LIDT 방법에 의해 갱신(update) 되지 않는다.
실재 테이블 크기는 고유 테이블 크기와 동일하거나 더 커야 한다. 만약 이 요구가 커널을 나누커널 구조로 이식할 때 부합되지 않으면, 실재 테이블 크기가 증가되거나 고유 테이블 크기가 감소되어야 한다.
적재 작업 레지스터 ( LTR , Load Task Register )
나노커널(nanokernel) 환경에서 IA-32 LTR 명령에 의해 작업 레지스터로 직 접 적재하는 대신, 그와 같이 하기 위하여 커널은 LTR 나노커널(nanokernel) 방법을 불러내야 한다. 이 방법은 주 커널을 위한 간접적인 호출과 보조 커널을 위한 트랩을 제외한, 주 커널 그리고 보조 커널과 유사하다.
프로세서 명령과 유사하게, LTR 나노커널(nanokernel) 방법은 작업 상태 세그먼트(TSS, task state segment )를 가리키는 세그먼트 선택기를 명시하는 오직 매개변수만을 취한다. 세그먼트 선택기(selector)에 의하여 지시된 상기 작업 상태 세그먼트가 언제나 상기 KV 매핑 (상기 주 커널조차) 안에 위치되어야 한다는 것을 강조하는 것이 중요하다.
유휴( Idle )
나노커널(nanokernel)은 유휴 루프 내에서 커널에 의해 호출되어야 하는 유휴 방법을 제공한다. 유휴 방법은 IA-32 Intel Hlt 명령에 상당하고 다음 인터럽트까지 할 일이 없는 커널을 호출하는 나노커널(nanokernel)에게 통지한다. 이 방법은 주 커널을 위한 간접적인 호출과 보조 커널을 위한 트랩을 제외하면 주 커널 그리고 보조 커널과 유사하다.
유휴 방법 불러내기는 다음의 실행할 준비가 된 보조 커널 (만약 이싸면)과 스위칭된 시스템 또는 모든 보조 커널이 유휴일 때 주 유휴 방법으로부터의 복귀로 결정된다. 유휴 방법은 어떤 매개변수도 가지고 있지 않다.
주 유휴 방법은 enabled(허용)된 프로세서 인터럽트와 함께 호출되어야 하고 비허용(disable) 프로세서 인터럽트와 함께 언제나 호출자로 돌아간다. 따라서, 나노커널(nanokernel) 유휴 방법으로부터 한번 되돌아오면, 주 커널은 다음 인터럽트까지 프로세서를 연기시키기 위하여 IA-32 hlt 명령을 따르는 IA-32 sti 명령을 직접적으로 실행할 수 있어야 한다.
보조 유휴 트랩은 enabled(허용)된 또는 비허용(disable)된 (소프트웨어) 인터럽트 중 하나에 의해 호출될 수 있고, enabled(허용)된 프로세서 인터럽트와 함께 언제나 호출자로 돌아간다. 사실, 보조 유휴 트랩은 인터럽트를 암시적으로 enabled(허용)하고, 인터럽트가 가상 예외(exception)(VEX)처럼 이 커널로 전달되면 호출자로 되돌아간다.
재시작 ( Restart )
나노커널(nanokernel)은 보조 커널을 재시작하기 위하여 보조 커널 뿐만 아니라 주 커널에 의해 호출될 수 있는 재시작 방법을 제공한다. 이 방법은 주 커널을 위한 간접적인 호출과 보조 커널을 위한 트랩을 제외하면 주 커널 그리고 보조 커널과 유사하다.
방법 매개변수는 재시작된 커널의 식별자를 명시한다. 나노커널(nanokernel)은 커널 수행을 정지하고, 그것의 사본으로부터 커널 이미지를 복원하며, 최종적으로 최초의 엔트리 지점에서 커널 수행을 시작한다.
보조 재부트 ( Secondary Reboot )
재부트(reboot) 트랩은 나노커널(nanokernel)에 의해 보조 커널로 제공된 다. 그러한 트랩은 그것이 재부팅될 때 보조 커널에 의해 호출된다. 이 트랩은 커널 그 자신을 호출한 재시작 트랩과 동등하다.
보조 정지 ( Secondary Halt )
정지 트랩은 나노커널(nanokernel)에 의해 보조 커널로 제공된다. 그러한 트랩은 그것이 정지될 때 보조 커널에 의해 호출된다. 나노커널널(nanokernel)은 나노커널(nanokernel) 스케줄러(schedular)에 의해 스위칭된 이 커널을 제거하기 위하여 호출자 커널을 비 실행 상태로 만들어야 한다.
하나의 정지된 커널은 위에서 설명한 재시작 나노커널(nanokernel) 방법에 의해 다시 시작될 수 있다.
주 실행 환경 ( Primary Execution Environment )
기본적으로, 주 커널은 고유 실행 환경에서 실행된다. IA-32 Intel 프로세서 상의 나노커널(nanokernel) 수행은 주 운영체제 특성(성능, 인터럽트 대기시간, 접수 대기시간)으로의 나노커널(nanokernel) 환경의 충돌을 최소화하려고 노력한다. 주 운영체제는 일반적으로 실시간 운영체제이기 때문이고, 다른 (보조) 운영체제가 동일한 프로세서 상에서 동시에 작동하고 있다고 하더라도 주 커널의 작용이 변화하지 않도록 유지하는 것이 중요하다.
초기화 ( Initialization )
나노커널(nanokernel)은 처음 비허용(disable) MMU와 함께, 즉, 물리적 공간에서 부트 로드에 의해 시작된다. 기본적으로, 나노커널(nanokernel) 초기화 코드는 물리적 메모리에서 ( 주 커널 코드/데이터/bss 섹션을 포함하는) 주 메모리 뱅크를 인스톨하고 주 엔트리 지점으로 점프한다.
주 커널로 점프하기 전에, 나노커널(nanokernel)은 주 커널 문맥을 초기화하고, 특히, 실재 GDT와 IDT를 초기 상태로 만든다.
초기의 주 GDT는 나노커널(nanokernel) 코드와 데이터 세그먼트를 명시하는 단지 두 개의 유효 엔트리만을 가지고 있다. 선택기는 커널 코드로 사용되고, 데이터 세그먼트는 나노커널(nanokernel) 인터페이스에 의해 각각 0x10과 0x18로 고정된다. 따라서, 커널을 IA-32 나노커널(nanokernel) 구조로 이식할 때, 코드와 데이터 선택기가 사용되어야 한다.
작업 레지스터와 마찬가지로 초기의 주 IDT에 있는 모든 게이트(gate)들은 실효성이 없다.(zeroed)
나노커널(nanokernel) 초기화 코드는 데이터 섹션에 위치한 정적 나노커널(nanokernel) 스택을 이용해 실행된다. 주 커널로 점프할 때, 이 스택은 여전히 유효하다. 그럼에도 불구하고, 주 커널은 가능한 빨리 그 자신만의 스택과 스위칭되어야 하며, 이후에는 이 나노커널(nanokernel) 스택을 절대 사용해서는 안된다. 나노커널(nanokernel) 스택은 다음 장에서 설명하듯이 보조 불러내기와 접수를 처리하기 위하여 초기화 단계 뿐만 아니라 실행시간에도 사용된다.
주 커널로 점프할 때, %esi 레지스터는 커널 문맥을 가리키고 eflag 레지스 터는 지워진다. 따라서, 프로세서 인터럽트는 주 초기화 단계의 초기에는 비허용(disable)된다. 주 커널은 보통 일단 중대한 초기화 단계가 완료되면 인터럽트를 가능하게 한다.
초기화 단계 동안, 주 커널은 일반적으로 GDT, IDT와 작업 레지스터를 ㅅ셋업(setup)하기 위하여 나노커널(nanokernel) 방법을 불러낸다. 마침내, 주 커널은 유휴 루프(loop)로 들어가고 나노커널(nanokernel) 유휴 방법을 불러낸다.
유휴 방법이 처음 호출될 때, 나노커널(nanokernel)은 주 커널이 그의 실행 환경을 완전히 초기화하고 초기화 뒷 단계까지 나아갈 것을 고려한다.
그러한 초기화 뒷단계에서, 나노커널(nanokernel)은 나노커널 메모리 문맥을 형성하고, 보조 커널 문맥을 다음 장에서 설명한 것과 같이 초기화한다. 나노커널(nanokernel) 메모리 문맥 발생은 번역 트리(tree)를 형성하기 위한 물리적 메모리의 할당을 요구하기 때문에 초기화 뒷단계까지 연기되지만, enabled(허용) 메모리 자원은 발견되고 커널 초기화 코드에 의해 기록된다. 초기화 뒷단계가 일단 한 번 완료되면, 나노커널(nanokernel)은 실행할 준비가 된 보조 커널과 스위치하거나, 모든 보조 커널이 유휴라면 주 유휴 방법으로부터의 복귀하기 위한 스케줄러(schedular)를 호출한다.
나노커널(nanokernel)은 주 커널이 범용 공유된 데이터 구조: RAM 디스트립터(디스크립터(descriptor))와 가상 장치 리스트,를 초기화하도록 요구한다. 그러한 초기화는 유휴 방법이 호출되기 전에 완료되어야 한다. 이 순간 후에 보조 커널은 범용 공유된 데이터 구조에 접근할 수 있기 때문에 이 요구는 자연스럽다.
특히, 주요 커널은 보드에서 사용가능한 물리적 메모리를 찾아내고 RAM 디스크립터(descriptor)에서 자유로운 물리적 메모리 덩어리를 기록하여야 하는 책임이 있다.
주 BSP(Board Support Package)에 의하면, 주 커널은 드라이버를 감지한 나노커널(nanokernel)을 시작해야 하고, 바로, 가상 장치 리스트를 차지해야 한다. 그러한 가상 장치들은 보조 커널로 제공되고 그러므로 첫 보조 커널이 시작되기 전 만들어져야 한다.
인터셉트된 예외 ( Intercepted Exceptions )
기본적으로, 나노커널(nanokernel)은 주 운영체제가 프로세서에서 실행되고 있을 때 발생하는 예외(exception)를 인터셉트하지 않는다. 모든 프로그래밍 예외(exception), 트랩, 그리고 인터럽트는 고유의 주 처리기에 의해 처리된다. 주 저-수준 처리기는 IA-32 Intel 나노커널(nanokernel) 구조로 이식될 때 수정될 필요가 없다.
위의 규칙에 따른 예외(exception)는 FPU 에뮬레이션과 관련 있는 프로그래밍 예외(exception)이다:
。무효 opcode 예외(exception) (#UD)
。예외(exception)가 enabled(허용)되지 않는 장치 (#NM)
FPU 에뮬레이션 특징은 앞으로 설명된 것과 같이 FPU 공유의 느린 메커니즘을 구현하기 위하여 나노커널(nanokernel)로 사용된다.
또 다른 특별한 경우는 주 운영체제의 호스트를 기초로 해 원격조정 시스템 디버깅를 제공하기 위한 나노커널(nanokernel)에 삽입할 수 있는 디버그 에이전트(agent)이다. 이 경우, 디버그 에이전트(agent)는 보통 이상에서 좀 더 일반적인 용어으로 설명된 특징 (예를 들어, 한개의 명령 추적(trace))을 디버깅하기 위하여서나, 에러 (예를 들어, 페이지 결함)를 프로그램하기 위한 것 중 하나와 관련있는 몇몇의 동기 예외(exception)를 인터셉트한다.
전달된 인터럽트 ( Forwarded Interrupts )
하나의 보조 운영체제가 프로세서에서 실행되는 동안 인터럽트가 발생할 때, 인터럽트는 주 운영체제로 전달된다. 그러한 인터럽트 전달 과정은 이하의 주된 단계를 통해 진행된다.
。인터럽트가 나노커널(nanokernel)에 의해 인터셉트 되는 단계;
。접수된 보조 커널의 실행이 중지되고 나노커널(nanokernel)이 주 실행 환경과 스위칭되는 단계;
。 나노커널(nanokernel)이 itn 명령을 사용하여 그에 상응하는 인터럽트를 주 커널로 트리거(trigger)하는 단계
이러한 방법에서 상응하는 주 저-수준 인터럽트 처리기는 ( 주 실행 환경 내에서) 인터럽트를 처리하기 위하여 불러내진다. 인터럽트가 한 번 처리되면, 주 커널은 iret 명령을 실행하는 나노커널(nanokernel)로 돌아간다.
주 인터럽트 처리기로부터 돌아온 뒤, 나노커널(nanokernel)은 실행시킬 다 음 보조 운영체제를 결정하기 위하여 스케줄러(schedular)를 호출한다. 접수된 보조 시스템은 인터럽트 이후에 지속 될 필요는 없다는 것을 유의하여야 한다. 또다른 (높은 순위의) 보조 시스템은 인터럽트를 이유로 동작할 준비를 할 수 있다.
보조 실행 환경 ( Secondary Execution Environment )
기본적으로, 보조 커널 실행 환경은 인터럽트 관리를 제외하면 고유의 실행 환경과 매우 밀접하다. 나노커널(nanokernel) 환경은 보조 운영체제를 완전히 접수할 수 있도록 만들기 위하여 인터럽트 관리의 고유 메커니즘을 수정한다. 나노커널(nanokernel) 구조로 이식된 보조 커널은 프로세서 수준에서 더이상 인터럽트를 비허용(disable)시키지 않고, 그보다는 나노커널(nanokernel)에 의해 제공된 메커니즘 (즉, 가상 예외(exception))을 금지하는 소프트웨어 인터럽트를 사용한다. 인터럽트는 더 이상 그러한 보조 커널에 의해 직접적으로 처리되지 않고, 그보다는 나노커널(nanokernel)에 의해 인터셉트되고 주 커널로 전달되며, 이후 단지 연기된 방식으로 보조 커널에 의해 부수적으로 처리된다.
초기화 ( Initialization )
나노커널(nanokernel)은 주 뱅크와 함께 초기화 시간에 보조 메모리 뱅크를 인스톨한다. 한편, 보조 커널의 최종 초기화는, 특히 커널 문맥 셋업(setup)에서, 초기화 뒷단계까지 연기된다.
이 단계에서, 나노커널(nanokernel)은 보조 메모리 뱅크의 사본을 유지하기 위하여 메모리를 할당한다. 그러한 사본은 곧 재시작 시간에 보조 시스템의 초기 이미지를 복원하는데 사용된다. 보조 시스템 재시작은 부수적이고 물리적 메모리 소비를 감소하기 위하여서 비허용(disable)될 수 있다.
주 커널과 유사한, 나노커널(nanokernel)은 커널 문맥의 숨겨진 부분에 위치한 (도 13 참조) 초기의 TSS와 마찬가지로 실재 GDT와 IDT를 초기화한다.
주 실재 GDT와 마찬가지로, 초기의 보조 실재 GDT는 나노커널(nanokernel) 코드와 데이터 세그먼트를 명시하는 두 개의 유효 엔트리를 가지고 있다. 나노커널(nanokernel) 코드와 데이터를 위한 세그먼트 선택기는 나노커널(nanokernel) 인터페이스에 의해 각각 0x10과 0x18로 할당된다. 또한, 보조 실재 GDT는 나노커널(nanokernel) 작업으로 사용된 사기 나노커널(nanokernel) TSS 데이터 구조를 명시하는 디스크립터(descriptor)를 포함한다. 그러한 나노커널(nanokernel) 작업은 다음 섹션에 설명된 것과 같이 보조 예외(exception)를 인터셉트하게끔 사용된다. 나노커널(nanokernel) TSS 디스크립터(descriptor)는 실재 GDT의 말미에 위치한다.
실재 IDT에 있어서, 나노커널(nanokernel)은 하드웨어 인터럽트와 나노커널(nanokernel) 트랩을 인터셉트하기 위하여 작업 게이트(gate)를 인스톨한다. 보조 초기화 시간에 치명적인 예외(exception)를 처리하기 위하여서 모든 다른 예외(exception) 역시 고유 IDT가 lidt 나노커널(nanokernel) 트랩에 의해 인스톨 될 때까지 나노커널(nanokernel)에 의해서 일시적으로 인터셉트된다. 그러한 두드러지는 (치명적인) 예외(exception)가 발생한다면 나노커널(nanokernel)은 단순히 보조 커널을 정지하지만, 주 시스템과 다른 어떤 보조 시스템도 방해하지 않는다. 일단 고유 IDT가 인스톨되면, 처음에 사용된 치명적인 예외(exception) 게이트(gate)는 고유 IDT에 의해 무효화된다. 그럴지라도 그것은 다음 섹션에 설명되는 영구히 인터셉트된 예외(exception)에 영향을 주지 않는다는 것을 유의하여야 한다.
나노커널(nanokernel)은 보조 커널 문맥에 위치한 초기 TSS와 스위치된 작업을 실행하는 보조 커널을 내보낸다. 도 14는 작업 스위칭에 앞서서 초기의 TSS가 어떻게 초기화되는지 보여준다. 모든 0 필드는 음영으로 표현되고, 0이 아닌 필드만 그림 상에 보여진다는 것을 유의하여야 한다.
주 커널과 유사하게, 커널 문맥의 물리적 주소는 %esi 레지스터로 전달된다. 한편, 주 커널과는 달리, 인터럽트 flag (IF)는 보조 커널 초기화 단계 동안조차 프로세서 인터럽트를 enabled(허용)하는 프로세서 flags 필드 (EFLAGS)에서 설정된다. 보조 커널 초기화 코드는 주 시스템에 의해 완전히 접수된다는 것을 유의해야 한다. 이는 특히 보조 운영체제가 재시작될 때 주 운영체제를 방해하지 않기 위하여서 중요하다.
enabled(허용)된 하드웨어 인터럽트에도 불구하고, 가상 예외(exception)는 (하드웨어 예외(exception)에 상응하는) 보조 커널이 시작되면 비허용(disable)된다. 따라서, 인터럽트는 결정적인 초기화 단계의 말미에 있는 커널에 의해 명시적으로 enabled(허용)되어야만 비로소 나노커널(nanokernel)에 의해 전달된다. 소프트웨어 인터럽트 금지 메커니즘은 (가상 예외(exception)를 기초로한) 앞으로 더욱 상세히 설명하도록 하겠다.
CR3 필드는 1 대 1 번역 트리(tree)를 가리킨다. 그러한 초기 1 대 1 매핑 은 보조 커널에 임시적으로 제공된다. 이 매핑은 수정거나 초기화 코드에 영구적으로 사용되어서는 안된다는 것을 유의해야 하며, 대신, 보조 커널은 그만의 KV 매핑에 형성되어야 하고 최대한 빨리 스위칭되어야 한다.
스택 포인터는 보조 커널이 시작되면 유효하지 않게 된다. 일반적으로, 보조 커널은 초기화 코드를 실행하기 위하여 데이터 섹션에 위치한 정적 초기화 스택을 이용한다.
초기화 단계 동안, 주 커널과 유사하게, 보조 커널은 일반적으로 GDT, IDT, 그리고 작업 레지스터를 셋업(setup)하기 위하여 나노커널(nanokernel) 트랩을 불러낸다. 최종적으로 보조 커널은 유휴 루프(loop)로 들어가고 나노커널(nanokernel) 유휴 트랩을 불러낸다.
인터셉트된 예외 ( Intercepted Exceptions )
하나의 보조 예외(exception)로 인터셉트하기 위하여, 나노커널(nanokernel)은 작업 게이트(gate)를 실재 IDT에 상응하는 엔트리로 인스톨한다. 따라서, 그러한 예외(exception)가 발생하면, IA-32 Intel 프로세서는 프로세서 상태를 현재 작업 상태 세그먼트 (TSS)로 저장하는 작업 스위칭을 실행하고 예외(exception) 작업 게이트(gate)로 명시된 TSS로부터 프로세서 상태를 복원한다.
인터셉트된 예외(exception) 각각을 위하여 나노커널(nanokernel)은, 실재 GDT에 위치한 전용 세그먼트 디스크립터(descriptor)에 의해 가리켜진 전용 TSS 데이터 구조를 새로 만든다. 그러한 나노커널(nanokernel) 세그먼트(나노커널 (nanokernel) TSS 데이터 구조로 사용된)는 실재 GDT의 말미에 위치한다. 모든 나노커널(nanokernel) TSS 데이터 구조는 나노커널(nanokernel) 실행 환경에 따라 유사하게 초기화된다. 도 15는 나노커널(nanokernel) TSS의 0이 아닌 필드를 보여준다. TSS 데이터 구조의 0이 된 부분은 그림에서 음영으로 표현되어 있다.
EIP 필드는 나노커널(nanokernel) 예외(exception) 작업의 주소를 포함한다. EBX 필드는 예외(exception) 디스크립터(descriptor)를 가리킨다. 다중의 인터셉트된 예외(exception)는 동일한 나노커널(nanokernel) 예외(exception) 작업 내에서 다중화될 수 있다. 예를 들어, 동일한 작업은 모든 하드웨어 인터럽트를 인터셉트하도록 사용되었다. 이 경우, 그러한 다중화된 작업은 예외(exception)가 특정한 정보를 획득할 수 있도록 예외(exception) 디스크립터(descriptor)(%ebx 레지스터에 enabled(허용)된)를 사용할 수 있다.
모든 인터셉트된 예외(exception)는 그 본질에 따라 인터럽트, 트랩, 그리고 프로그래밍 예외(exception)(결점)와 같이 분류될 수 있다.
나노커널(nanokernel)은 주 커널로 전달하기 위하여 모든 하드웨어 인터럽트(금지되지 않은 인터럽트(NMI)를 포함하는)를 인터셉트한다.
나노커널(nanokernel)에 의해 인터셉트된 트랩은, 사실 이하의 나노커널(nanokernel) 불러내기이다.
。범용 트랩
。XIRQ 트랩
。STI 트랩
。IRET 트랩
범용 트랩은 콘솔 I/O, lgdt/sgdt, lidt/sidt, 정지, 재부트(reboot), 재시작과 같은 비실행의 결정적인 나노커널(nanokernel) 불러내기를 결합한다. 나노커널(nanokernel) 방법의 수와 매개변수는 통상적인 트랩으로서의 범용 레지스터로 전달되어야 한다. 범용 트랩은 %eax 레지스터에 코드화된 번호에 따른 나노커널(nanokernel) 방법을 불러내는, 공통 예외(exception) 작업에 의해 처리된다.
나머지 세 개의 트랩은 결정적인 실행이고, 특정한 나노커널(nanokernel) 작업에 의해 처리된다. 이 트랩들은 매개변수가 없다.
XIRQ 트랩은 주 커널로 교차 인터럽트를 송신한다. XIRQ 트랩 작업은 하드웨어 인터럽트보다 소프트웨어 인터럽트에 상응하는 주 커널로 전달되는 예외(exception)를 제외하면 인터럽트 작업과 일치한다. 따라서, 인터럽트와 같이, XIRQ 트랩은 현재 보조 커널을 접수한다.
STI와 IRET 트랩 양 치는 pending(미결) 가상 예외(exception)를 처리하기 위하여 보조 커널에 의해 호출된다. 이 트랩들은 소프트웨어 인터럽트 금지 메커니즘에 가담하고, 이는 가상 예외(exception)를 나타내는 다음 섹션에 좀 더 자세히 설명하기로 한다.
주 커널과 유사하게, 나노커널(nanokernel)은 일반적으로 이하 설명된 몇몇의 특별한 경우를 제외하고는 프로그래밍 예외(exception)를 인터셉트하지 않는다.
나노커널(nanokernel)은 상기 FPU 에뮬레이션과 관련된 이하의 예외 (exception)를 인터셉트한다:
。유효하지 않은 op코드(opcode) 예외(exception) (#UD)
。예외(exception)가 유효하지 않은 장치 (#NM)
FPU 에뮬레이션 특징은 앞으로 설명 될 것과 같이 FPU 공유의 느린 메커니즘을 수행하기 위하여 나노커널(nanokernel)에 의해 사용된다.
또 다른 특별한 경우는 호스트에 기초하여 보조 운영체제의 원격조정 시스템 디버깅를 제공하기 위하여, 나노커널(nanokernel)에 삽입할 수 있는 디버그 에이전트(agent)이다. 이 경우, 디버그 에이전트(agent)는 보통, 디버그 특징 (예를 들어, 한개의 명령 추적(trace)이나 프로그램 에러 (예를 들어, 페이지 결함) 중 하나와 관련있는 몇몇의 동기된 (synchronous) 예외(exception)를 인터셉트한다. 그러나, 이러한 디버그 에이전트의 설계는 본 명세서의 범위를 벗어나는 것이다.
가상 예외 ( Virtual Exceptions )
가상 예외(VEX)는 커널이 예외(exception)를 보조 커널로 우송하고, 그것을 지연된 방법으로 전달하는 것을 enabled(허용)하는 나노커널(nanokernel)에 의해 제공되는 메커니즘이다. 특히, VEX 메커니즘은 보조 커널을 위하여 하드웨어 인터럽트를 소프트웨어 인터럽트로 대체하기 위하여 IA-32 Intel 나노커널(nanokernel) 구조에서 사용된다.
VEX 인터페이스는 커널 문맥에 위치한 pending (미결)enabled (허용)의 두 개의 필드로 구성된다. 이 필드들은 오직 보조 커널 문맥에 대해서만 의미가 있지 만, 주 커널과 보조 커널 양쪽 모두에 의해 접근된다. 모든 가상 예외(exception)는 pending (미결) (또는 enabled (허용)) 필드 내에서의 비트의 위치에 의해 자연스럽게 열거된다. 따라서, IA-32 구조( pending (미결) 필드와 enabled(허용) 필드는 32 비트 정수 값이다.) 상의 나노커널(nanokernel)에 의해 지원되는 총 32개의 가상 예외(exception)가 있다.
아래의 표는 가상 예외(exception)가 어떻게 실재 가상 예외(exception)에 매핑되는지 보여준다.
가상 예외(exception) 실재 예외(exception) 비고
0 2 NMI
1-16 32-47 IRQ0-IRQ15
17 48 교차 인터럽트
18-30 - -
31 - 실행(Running)
0부터 16까지의 가상 예외(exception)는 하드웨어 인터럽트에 매핑되었다. 가상 예외(exception) 17은 교차 인터럽트를 보조 커널로 전달하는데 사용된 실재 예외(exception) 48에 매핑되었다. 18부터 30까지의 가상 예외(exception)는 현재 사용되지 않고 미래의 확장을 위하여 보류된다. 가상 예외(exception) 31은 어떠한 실재 예외(exception)와도 일치하지 않고, 사실상 커널이 유휴인지 감지하기 위한 의도로 나노커널(nanokernel)에 의해 내부적으로 사용되는 유사(pseudo) 가상 예외(exception)이다. 그러한 유사 가상 예외(exception)가 어떻게 작동하는지는 앞으로 자세히 설명할 것이다.
다중의 가상 예외(exception)는 동일한 시간에는 pending(미결)일 수 있지만 오직 한개의 가상 예외(exception)만이 그 시간에 처리될 수 있고, 모든 가상 예외(exception)는 그것의 숫자에 따라 우선순위가 조정된다. 가장 높은 순위는 NMI에 할당되고 가장 낮은 우선 순위는 실행(Running)에 할당된다.
보조 문맥의 pending (미결) VEX 필드는 일반적으로 가상 PIC 장치를 위한 드라이버를 제공하는 주 커널에 의해 갱신(update) 된다. 그러한 드라이버는 일반적으로 pending (미결) VEX 필드 내에서 적절한 비트를 조정함으로써 가상 예외(exception) (인터럽트)를 보조 커널로 운송한다.
enabled (허용) VEX 필드는 가상 예외(exception)를 enabled(허용) 또는 비허용(disable)하기 위하여 보조 커널에 의해 갱신(update)된다. 상응하는 비트가 enabled(허용) VEX 필드에 설정된다면, 주어진 가상 예외(exception)는 enabled(허용)된다. enabled (허용) VEX 필드를 이용하여 보조 커널은 인터럽트를 보호하는 결정적인 섹션을 수행한다. 달리 말해, 보조 커널은 더이상 비허용(disable)/enabled(허용) 프로세서 인터럽트에 clisti A-32 명령을 사용하기보다는 그것의 커널 문맥의 enabled(허용) VEX 필드를 수정한다.
하나의 주어진 가상 예외(exception)는 만약 그것이 동시에 pending(미결)되고 enabled(허용)된다면 나노커널(nanokernel)에 의해 전달된다. 나노커널(nanokernel)은 보조 예외(exception) 처리기에 점프하기 전에 상응하는 pending(미결) 비트를 재설정한다.
하나의 가상 예외(exception)를 보조 커널로 전달할 때, 나노커널 (nanokernel)은 상기의 고유 IDT로부터 게이트(gate) 디스크립터(descriptor)를 번역한다. 보조 커널의 저 수준 처리기에서의 수정을 최소화하기 위하여, 나노커널(nanokernel)은 IA-32 Intel 프로세서가 하듯이 동일한 상태에서 게이트(gate) 처리기를 호출한다. 달리 말해, 나노커널(nanokernel)은 스택 포인터와 코드 및 스택 세그먼트 스위치하고, IA-32 Intel 프로세서와 같은 방식으로 예외(exception) 프레임을 관리자 스택으로 밀어넣는다.
그럼에도 불구하고, 보조 커널을 IA-32 나노커널(nanokernel) 구조로 이식할 때, 저 수준 예외(exception) 처리기는 하드웨어 인터럽트 금지 메커니즘을 대신하는 소프트웨어 인터럽트 금지 메커니즘을 고려하기 위하여 여전히 수정되어야 한다. 인터럽트 게이트(gate) 처리기를 호출할 때, 나노커널(nanokernel)은 enabled(허용) 필드의 0x80000000을 쓰는 모든 가상 예외(exception)를 단지 비허용(disable)하기만 한다. 하드웨어 인터럽트는 언제나 보조 커널을 실행할 때 프로세서 수준으로 enabled(허용)되고, 따라서 보조 커널은 저 수준 인터럽트 게이트(gate) 처리기 안에서조차 주 커널에 의해 접수될 수 있다. 이렇게 하여, 나노커널(nanokernel) 환경에서, 보조 운영체제는 주 운영체제에 의해 완전히 접수된다.
하나의 가상 예외(exception)는 비허용(disable) 상태 동안 부 커널에 의해 운송될 수 있다. 이 경우, 예외(exception)는 보조 커널로 전달되지 않고, 오히려 예외(exception)가 다시 재-enabled(허용)될 때까지 pending(미결) 상태를 유지한다. 따라서, 가상 예외(exception)가 보조 커널에 의해 재-enabled(허용)될 때, 어떠한 가상 예외(exception)라도 미결로 남아 있는지 점검되어야 한다. 만약 점검 결과가 양(positive)라면, 보조 커널은 그러한 pending(미결) 가상 예외(exception)를 처리하기 위하여 나노커널(nanokernel)을 불러내야 한다. 그러한 불러내기는 STI 또는 IRET 트랩 중 수단에 의해 수행된다.
일반적으로, 보조 커널은 이하 두 개의 경우에 있어서 가상 예외(exception)를 재-enabled(허용)한다;
。가상 예외(exception)가 코드의 결정적인 섹션을 보호하기 위하여 보조 커널에 의해 미리 비허용(disable)될 때
。가상 예외(exception)가 인터럽트 게이트(gate) 불러내기의 결과에 따라 나노커널(nanokernel)에 의해 비허용(disable)될 때
전자의 경우, 보조 커널은 pending(미결) 가상 예외(exception)가 만약 있다면 그것을 처리하기 위하여 STI 트랩을 사용한다. 일단 pending(미결) 예외(exception)가 처리되면, 나노커널(nanokernel)은 보조 커널 실행을 지속하기 위하여 STI 트랩으로부터 되돌아 온다.
후자의 경우, 보조 커널은 예외(exception) 처리기로부터 되돌아 올 때 pending(미결) 가상 예외(exception)를 처리하기 위하여 IRET 트랩을 사용한다. IRET 트랩이 단지 iret IA-32 명령을 대신하고, 트랩이 실행될 때, 실행 프레임은 여전히 관리자 스택으로 밀어 넣어진다는 것을 유의하여야 한다. 나노커널(nanokernel)이 IRET로부터 되돌아 오지 않고, 대신 일단 pending(미결) 예외(exception)가 처리되면, 보조 운영체제 실행은 초기 가상 실행에 의해 접수된 지점에서 지속된다는 것 역시 유의하여야 한다. 다시 말해, IRET 트랩은 트랩 시간에 스택의 꼭대기에 위치한 예외(exception) 프레임 내에서 저장된 상태로 되돌아간다는 것이다.
나노커널 재-진입 ( Nanokernel Re - Entrance )
나노커널(nanokernel) 코드는 대부분 커널 내에서의 재-진입을 예방하기 위하여 프로세서 수준에서 비허용(disable)된 인터럽트와 함께 실행된다. 다른 한 편으로는 몇몇의 나노커널(nanokernel) 불러내기는 긴 시간을 소요하고, 따라서 나노커널(nanokernel)은 주 인터럽트 대기 시간을 짧게 유지하기 위하여서 그러한 긴 작동을 실행할 때 인터럽트를 enabled(허용)해야 한다.
긴 나노커널(nanokernel) 작동에는 세 종류가 있다:
。동기식 콘솔 출력
작동 존속기간은 직렬 회선의 속도에 달려있다. 예를 들어, 9600 baud 비율 라인에서, 단일 문자 출력은 1ms를 차지할 것이다.
。lgdt 와 lidt
작동 지속기간은 직렬 회선의 테이블의 크기에 달려있다. 어찌됐든 인터럽트가 일반적으로 비허용(disable)될 때 통상적으로 초기화 시간에 나타나기 때문에, 이 작동은 여전히 주 커널을 위하여 비허용(disable)된 인터럽트와 함께 완료될 수 있다. 그러나 보조 igdt와 ligt 방법을 위해서는, 보조 커널이 어떠한 시간에도 재시작 될 수 있기 때문에 비허용(disable)된 인터럽트를 유지하는 것은 명확히 받아들일 수 없다.
。보조 커널 재시작
작동 지속기간은 사본으로부터 복원된 커널 이미지의 크기에 달려있다.
위에 나열한 모든 작동에 대해, 나노커널(nanokernel)은 인터럽트를 enabled(허용)하고 따라서 주 커널로부터 재-진입을 허용한다. 한편, 다른 보조 커널이 주 인터럽트 처리기로부터 되돌아올 때 다른 보조 커널이 예정되는 것을 막기 위하여, 인터럽트가 enabled(허용)되는 동안 나노커널(nanokernel) 스케줄러(schedular)는 비허용(disable)된다. 달리 말해, 나노커널(nanokernel)은 오직 주 커널에 의해서만 접수될 수 있지만 (하나의 인터럽트의 결과로서) 보조 커널로부터의 재-진입은 금지된다. 그러한 제한은 나노커널(nanokernel)이 보조 실행 환경을 위하여 범용 자원을 이용하는 것을 enabled(허용)한다. 예를 들어, 인터셉트된 예외(exception)에 사용된 TSS 데이터 구조는 범용이고 모든 보조 커널에 걸쳐 공유된다.
하나의 보조 커널로부터 발생된 약간의 긴 동작은 주 메모리 문맥내에서 실행될 수 있다. 다시 말해, 그러한 하나의 동작을 실행하기 전에, 나노커널은 주 실행 문맥으로 스위치되고 이후 인터럽트를 허용한다. 일단 상기 동작이 완료되고 나면, 나노커널은 인터럽트를 비허용(disable)하고 나노커널 스케줄러를 통해 호출자 보조 커널로 되돌아온다.
아무리 그렇다고 하더라도 몇몇의 긴 작동은 보조 KV 매핑에 위치한 데이터 구조로의 접근을 요구하기 때문에 주 메모리 문맥에서 실행될 수 없음을 유의하여야 한다. 그러한 작동의 일반적인 예는 고유의 GDT와 IDT 데이터 구조 각각에 접근 하는 보조 lgdt와 lidt 방법이다. 따라서, 이 작동들은 나노커널(nanokernel) 메모리 문맥에서 완료되어야 한다.
주 실행 환경으로/로부터의 스위칭에 의해 투입된 여분의 오버헤드를 제거하기 위하여 나노커널(nanokernel) 메모리 문맥 안에서 (그것들은 또한 주 메모리 문맥에서 실행될 수 있다고 해도) 나노커널(nanokernel) 방법을 이용해 빈번히 실행되는 것이 바람직하다는 것 또한 유의하여야 한다. 그러한 빈번한 작동의 일반적인 예는 나노커널(nanokernel) 콘솔 상의 동기식 출력이다.
이상의 논의는 활성화된 보조 GDT와IDT와 함께 나노커널(nanokernel) 메모리 문맥 안에 있는 코드를 실행하는 동안 나노커널(nanokernel)이 프로세서 인터럽트를 enabled(허용)하는 것이 가능하여야 한다는 것을 보여준다. 바꾸어 말하면, 보조 나노커널(nanokernel) 방법을 실행하는 트랩 작업을 작동하는 동안, 나노커널(nanokernel)은 인터럽트 작업으로 스위칭하는 작업을 지원해야 한다.
그러한 작업 중첩(nesting)을 지원하기 위하여서, 나노커널(nanokernel)은 도 13에 나타낸 커널 문맥의 숨겨진 부분에 위치한 커널-당 TSS 스택을 처리한다. 이 데이터 구조는 보조 커널 문맥에 대해서만 의미가 있다. 스택의 꼭대기는 현재 TSS, 즉, 작업 레지스터에 의해 가리켜진 TSS를 가리킨다. 스택은 작업 스위칭이 보조 커널로/로부터 실행되는 각각의 시간에 갱신(update) 된다. 나노커널(nanokernel) 작업이 작업 게이트(gate)에 의해 활성화될 때, 작업 TSS는 스택으로 밀어 넣어진다. 나노커널(nanokernel)이 나노커널(nanokernel) 작업으로부터 되돌아올 때, 꼭대기 TSS는 스택으로부터 제거된다. TSS 스택은 또한 스택의 바닥에 위 치한 고유 보조 TSS를 변경하는 보조 ltr 방법에 의해 갱신(update) 된다.
도 16은 TSS 스택의 일반적인 상태를 보여준다. 그림의 절반 위쪽은 보조 커널이 인터럽트에 의해 접수될 때의 TSS 스택 평가를 표현한다. 그림의 절반 아래쪽은 나노커널(nanokernel)이 인터럽트에 의해 접수된 긴 보조 커널을 실행할 때의 TSS 스택 평가를 표현한다. TSS 스택은 절대로 빌(empty) 수 없고 최대 스택 깊이는 3까지로 제한된다는 거을 유의하여야 한다.
고유 TSS는 언제나 스택의 바닥에 위치한다. 이 TSS는 고유 보조 커널 실행 환경에 의하여 사용된다. 위에 설명된 것과 같이, 보조 커널은 커널 문맥의 숨겨진 부분에 위치한 초기의 TSS를 이용해 시작한다. 초기화 단계 동안, 보조 커널은 일반적으로 ltr 나노커널(nanokernel) 방법을 이용해 자신만의 고유 TSS를 인스톨한다. 그러한 고유 TSS는 TSS 스택에 있는 초기의 것을 무시(override)한다.
일단 하나의 보조 커널이 인터럽트에 의해 한 번 접수되거나, 나노커널(nanokernel) 방법이 트랩을 통해 불러내지면, 그에 상응하는 나노커널(nanokernel) 작업이 작업 게이트(gate)에 의해 활성화된다. 나노커널(nanokernel) 작업은 언제나 자신만의 TSS로 향하는 포인터를 스택 안으로 밀어넣는다. 인터럽트의 경우, 나노커널(nanokernel) 인터럽트 작업은 인터럽트를 처리하기 위하여 단순히 주 커널로 스위칭만 한다. 트랩의 경우, 나노커널(nanokernel)은 긴 방법의 코드를 실행하는 동안 인터럽트를 enabled(허용)할 수 있다.
인터럽트가 enabled(허용)될 때, 나노커널(nanokernel) 방법은 작업 게이트(gate)와 인터럽트 작업에 의해 활성화된 나노커널(nanokernel) 인터럽트 작업에 의해 접수될 수 있고, 이어서, 인터럽트를 처리하기 위하여 주 커널로 스위칭한다. 일단 인터럽트가 처리되면, 주 커널은 인터럽트 방법의 실행을 재개하기 위하여서 나노커널(nanokernel)로 되돌아온다.
트랩과 인터럽트 작업은 중첩(nest)될 수 있으므로, 작업 코드를 실행할 때 다른 (겹쳐지지 않은) 스택을 사용하는 것이 필요하다. 나노커널(nanokernel)은 인터럽트 작업 내dml 특별한 인터럽트 스택을 사용한다.
트랩 작업에서 인터럽트가 발생하면, 프로세서는 인터럽트 작업으로 스위칭하고 범용 레지스터를 트랩 작업 TSS (이 순간에서의 현재의 TSS)에 저장한다. 따라서, 트랩 작업에서 인터럽트가 일단 비허용(disable)되면, 인터럽트에 의해 오류가 생길 수 있으므로 트랩 TSS의 EIP, EBX, 그리고 ESP 필드를 재-초기화하는 것이 필요하다.
스케줄러 ( Scheduler )
운영체제 스케줄러(schedular)의 주된 역할은 다음에 실행될 작업을 선택하는 것이다. 나노커널(nanokernel)이 운영체제의 실행을 제어하기 때문에, 나노커널(nanokernel) 스케줄러(schedular)는 다음에 실행될 보조 운영체제를 선택해야 한다. 다시 말해, 나노커널(nanokernel)은 전체 시스템에 부수적인 스케줄링 수준을 추가하는 것이다.
나노커널(nanokernel) 구조에서, 주 운영체제는 보조 운영체제에 비해 높은 우선순위 순위를 가지고, 주 운영체제가 오직 유휴 루프(loop)에 있을 때에만 CPU 가 보조 운영체제에 주어진다는 것을 유의하여야 한다. 주 커널은 접수할 수 없고, 유휴 루프(loop)에 호출된 유휴 방법을 통해 나노커널(nanokernel) 스케줄러(schedular)를 명시적으로 불러낸다고 말할 수 있다. 일단 보조 운영체제를 실행할 때 인터럽트가 발생하면, 주 커널 인터럽트 처리기가 불러내진다. 주 커널 투시도(perspective)로부터 그러한 인터럽트는 유휴 루프(loop)를 실행하는 배경 스레드를 접수한다. 일단 인터럽트가 처리되고 모든 관계된 작업이 완료되면, 주 커널은 다음에 실행할 보조 운영체제를 결정하기 위하여 나노커널(nanokernel) 스케줄러(schedular)를 불러내는 나노커널(nanokernel)로 되돌아간다. 커널은 단지 인터럽트에 의해 주 커널 투시도로부터 접수된 배경 스레드로 되돌아간다. 보조 활동은 주 커널을 위하여 투명(transparent)하고, 주 운영체제의 거동(behaviour)을 변화시키지 않는다.
나노커널(nanokernel)은 다른 스케줄링 방침을 수행할 수 있다. 그러나 디폴트로 알고리즘을 기초로 한 우선순위가 사용된다. 동일한 우선순위 수준에서, 나노커널(nanokernel)은 라운드-로빈(round-robin) 스케줄링 방법을 이용한다는 것을 유의하여야 한다. 주어진 보조 커널 우선순위는 시스템 이미지 형성 시간에 정적으로 구성된다.
수행되는 스케줄링 방침이 무엇이든, 스케줄러(schedular)는 주어진 보조 운영체제가 작동할 준비가 되었는지를 감지해야 한다. 이 조건은 커널 문맥의 pending (미결) VEXenabled (허용) VEX 필드 사이에서 비트의 논리와 작동에 의해 산출된다.
위에 설명된 것과 같이, pending (미결) VEXenabled (허용) VEX 쌍에 있는 각각의 비트는 가상 예외(exception)를 나타낸다. 작동할 준비가 된 기준을 바꾸어 말한다면, 금지되지 않은 pending(미결) 가상 예외(exception)가 적어도 하나 이상 있다면 보조 운영체제는 작동할 준비 상태에 있다고 말할 수 있는 것이다.
일반적으로 하드웨어와 소프트웨어 (교차) 인터럽트에 매핑된 모든 가상 예외(exception) 사이에, 커널이 현재 유휴인지를 반영하는 특별한 가상 예외(실행)가 있다.
running (실행) 비트는 보조 커널이 유휴 방법을 불러내는 각각의 시간에 pending(미결) VEX 필드에서 지워지고, running (실행) 비트는 가상 예외(exception)가 보조 커널로 전달되는 각각의 시간에 pending(미결) VEX 필드에서 설정된다.
running (실행) 비트는 보통 실행되는 보조 커널을 위하여 enabled (허용) VEX 필드 내에 설정된다. 나노커널(nanokernel)은 보조 커널이 시작될 때 이 비트를 설정하고, 그것은 보조 커널이 정지할 때 이 비트를 재설정한다. 보조 커널은 가상 예외(exception)에 매핑된 인터럽트가 금지된/금지되지 않은 때에 running(실행) 비트를 절대 지울 수 없다.
하나의 외부 에이전트(agent)는 보조 커널 문맥 내에서 enabled (허용) VEX 필드를 지움/복원함으로써 보조 커널 실행을 연기/재개할 수 있음을 유의하여야 한다.. 이 특징은 주 커널 작업과 마찬가지로 스케줄링 방침 에이전트(agent)가 나노커널(nanokernel) 밖에서 수행될 수 있는 가능성을 열어준다. 또한, 이는 보조 커 널이 주 커널의 꼭대기 상의 작업과 같이 실행될 수 있는 디버그 에이전트(agent)를 가능하게 한다. 그러한 보조 디버그 에이전트(agent)의 이점은, 주 운영체제에 의해 제공된 모든 서비스가 디버깅에 가용될 수 있다는 점이고, 보조 커널 디버깅는 주 운영체제 상에 실행되는 결정적인 작업과 동시에 완료될 수 있다는 점이다.
교차 인터럽트 ( Cross Interrupts )
이 섹션에서는 주로 나노커널(nanokernel) 교차 인터럽트 메커니즘과 관계있는 (전 섹션에 이미 주어진)정보를 통합할 것이다.
여기서는 아래와 같은 두 종류의 교차 인터럽트가 논의될 것이다:
。하나의 보조 커널로 송신된 교차 인터럽트
。하나의 주 커널로 송신된 교차 인터럽트
하나의 교차 인터럽트를 수신지(destination) 보조 커널로 송신하기 위하여 소스 터널은 우선 수신지 커널 문맥의 pending (미결) XIRQ에 있는 교차 인터럽트 소스에 상응하는 비트를 설정한다. 그 다음 소스 커널은 교차 인터럽트 VEX를 수신지 커널 문맥의 pending (미결) VEX 필드에 있는 상응하는 비트를 설정한 수신지 커널로 발송한다. 일단 교차 인터럽트 처리기가 나노커널(nanokernel)에 의해 호출ㄷ되면, 그것은 pending (미결) XIRQ 필드를 점검하고, pending(미결) 교차 인터럽트 소스에 상응하는 비트를 지우며, 최종적으로 이 소스에 부착된 처리기를 불러낸다. 소스와 수신지 커널 둘 다 pending (미결) XIRQ 필드를 갱신(update)하기 위하여 원자 명령(atomic instruction)을 사용한다. 소스 커널의 두 타입인 주와 보조 모두 동일한 알고리즘을 사용한다는 것을 유의하여야 한다.
주 커널로 교차 인터럽트를 송신하기 위하여, 보조 커널은 우선 주 커널 문맥의 pending (미결) XIRQ에 있는 상기 교차 인터럽트 소스에 상응하는 비트를 설정한다. 그 다음, 보조 커널은 XIRQ 트랩을 실행하는 나노커널(nanokernel)을 불러낸다. 나노커널(nanokernel)은 보조 커널을 곧바로 접수하고, pending (미결) XIRQ 필드를 점검하는 주 저-수준 교차 인터럽트 처리기를 불러내며, pending(미결) 교차 인터럽트 소스에 상응하는 비트를 지우고, 최종적으로 이 소스에 부착된 처리기를 불러낸다.
교차 인터럽트 0을 커널이 사용해서는 안된다. 이 인터럽트는 정지된 커널은 시작되는지 또는 실행된 커널이 정지되는지를 커널에 고지할 수 있도록 나노커널(nanokernel)을 위하여 보존된다. 다시 말해, 교차 인터럽트 0은 범용 시스템 구성이 변경되면 이를 실행 커널에 고지해야 한다. 이는 상기의 실행 필드가 커널 문맥에서 변경되는 각각의 시간에 모든 실행 커널로 넓게 전파된다.
FPU 관리 ( FPU Management )
FPU 엔진은 일반적으로 나노커널(nanokernel) 환경에서 실행되는 모든 운영체제에 의해 공유된 계산 자원이다.
IA-32 Intel 구조에서, 나노커널(nanokernel)은 느린 방법에 의해 FPU 공유를 관리한다. 이는 운영체제로부터 다른 운영체제로의 스위칭이 발생할 때, FPU 엔진이 새롭게 스케줄링 된 운영체제를 대신해 곧바로 주어지지 않고, FPU 스위칭은 새롭게 스케줄링 된 운영체제가 실제로 부동 소수점 명령을 실행하고 부동 소수점 레지스터에 접근할 때까지 연기된다는 뜻이다.
그러한 느린 FPU의 발송(dispatching) 알고리즘은 나노커널(nanokernel)이 시스템 스위칭 시간을 감소시키도록 enabled(허용)한다. 이는 FPU가 일반적으로 인터럽트 수준에서 사용되지 않기 때문에 주 인터럽트 대기시간을 감소시키기 위하여 특히 중요하고, 따라서 보조 운영체제를 접수하고 주 인터럽트 처리기를 호출하기 위하여 FPU 레지스터를 저장하고 복원하는 것은 일반적으로 항상 필요한 것은 아니다.
나노커널(nanokernel)은 현재 FPU를 사용하는 커널의 문맥을 가리키는 FPU 소유자 범용 변수를 처리한다. FPU 소유자가 없을 경우, FPU 소유자 문맥은 0으로 설정된다. FPU 문맥은 커널 문맥의 숨겨진 부분에 위치한다. 커널이 FPU의 소유자가 아닐 때 그러한 문맥은 FPU 엔진의 상태(즉, 부동 소수점 레지스터와 상태)를 유지한다. 명백히, FPU 소유자의 상태는 FPU 엔진 하드웨어에 의해 보호된다. 나노커널(nanokernel)이 FPU 소유자를 변경할 때, FPU 상태는 예전의(old) FPU 문맥에 저장되고 새로운 FPU 문맥으로부터 복원된다.
나노커널(nanokernel)은 FPU가 FPU 소유자가 아닌 것에 의하여 사용될 때 예외(exception)를 호출하기 위하여, CR0 레지스터의 에뮬레이션 비트(EM)를 사용한다. CR0 레지스터 이미지는 커널 문맥의 숨겨진 부분에 첨가한다. CR0 레지스터는 시스템 스위칭에서 (에전의 문맥으로) 저장되고 (새로운 문맥으로부터) 복원된다. EM 비트는 그것이 지워지는 곳인 FPU 소유자를 제외한 모든 커널 문맥에 설정 된다. 이에 더하여, FPU 소유자가 고유의 방법에 의해 이러한 예외(exception)를 처리하는 동안, 상기 나노커널(nanokernel)은 적절하지 않은 op코드(#UD)와 유효하지 않은 장치(#NM)의 FPU 소유자가 아닌 모든 것들을 위한 예외(exception)를 인터셉트한다.
하나의 FPU 스위치는 나노커널(nanokernel)이 FPU와 관련된 예외(exception)와 관련된 FPU, 즉 #UD 또는 #NM 중 하나를 인터셉트할 때 발생한다. 두 개의 커널 사이에서 FPU 엔진을 스위칭하기 위하여, 나노커널(nanokernel)은 현재 FPU 소유자를 내보내고(release) 새로운 FPU 소유자를 할당한다.
현재의 FPU 소유자를 내보내기 위하여 나노커널(nanokernel)은 커널 문맥 안에 현재 FPU 상태를 저장하고, CR0 레지스터 이미지에 EM 비트를 설정한다. 또한, 나노커널(nanokernel) 게이트(gate)는 #UD와 #NM 예외(exception)를 인터셉트하기 위하여 실재 IDT 안에 인스톨 된다.
새로운 FPU 소유자를 할당하기 위하여 나노커널(nanokernel)은 커널 문맥 안에 FPU 상태를 복원하고, CR0 이미지에 있는 EM 비트를 지운다. 또한, 고유의 게이트(gate)는 FPU를 소유하는 동안 고유의 방법으로 #UD와 #NM 예외(exception)를 처리하기 위하여 실재 IDT 안에 인스톨 된다.
나노커널(nanokernel)은 저장과 복원 동작을 최적화하기 위하여 CR4 레지스터의 OSFXSR 비트를 사용한다. CR4 레지스터 이미지는 커널 문맥의 숨겨진 부분에 참가한다. 이것은 시스템 스위칭에서 (예전의 문맥으로) 저장되고 (새로운 문맥으로부터) 복원된다. 나노커널(nanokernel)은 어떠한 타입, 즉 표준 또는 확장된 타 입이 저장되고 복원되어야 하는지 결정하기 위하여 CR4 레지스터 이미지를 사용한다. 이는 나노커널(nanokernel)이 MMX나 SIMD 특징 중 어떠한 것도 사용하지 않는 운영체제를 위하여 확장된 FPU 문맥을 저장/복원하지 않는 것을 enabled(허용)한다.
나노커널(nanokernel)이 느린 FPU 스위칭을 수행하기 위하여 CR0 레지스터의 EM 비트를 사용하기 때문에, 커널은 이 비트의 상태를 변경하는 것이 enabled(허용)되지 않는다. 특히, 이는 FPU 에뮬레이션이 나노커널(nanokernel) 구조로 이식된 나노커널(nanokernel)에 의하여 지지되지 않는다는 것을 의미한다.
일반적으로 운영체제 커널은 프로세서 사이에서의 느린 FPU 스위칭을 이행하기 위하여 CR0 레지스터의 TS 비트를 사용한다는 것을 유의하여야 한다. CR0 레지스터 이미지가 커널 문맥에 참가하고, 따라서 시스템 스위칭에서 저장되기 때문에, 복원되고, 고유 FPU 관리는 나노커널(nanokernel) 환경에서 거의 변하지 않고 유지될 수 있다.
그러나 TS 비트가 작업 스위칭에 의해 자동적으로 설정된다는 것을 유의하여야 한다. 이는 커널의 관점에서 TS 비트가 논리적으로 지워질지라도 FPU 예외(exception)가 보조 커널 내에 발생할 수 있다는 뜻이다. 그러한 가짜 FPU 예외(exception)는 보조 예외(exception)를 인터셉트하기 위하여 나노커널(nanokernel)을 이용한 작업 게이트(gate)에 의해 유입된다. 그러한 가짜 FPU 예외(exception)를 감지하고 조용히 그들을 무시(단지 TS 비트를 지우는)하기 위하여, 보조 커널은 TS 비트의 소프트웨어 사본을 처리해야 한다. 커널 문맥 안에서 이러한 목적을 위 하여 전용되는 필드를 제공하는 이러한 작업 내의 나노커널(nanokernel)은 보조 커널을 돕는다.
다른 측면들과 실시예들
전술한 실시예는 다만 사례일 뿐이고 많은 다른 실시예가 가능하다는 것은 명세서 서두에서부터 분명할 것이다. 앞서 언급한 운영체제, 플랫폼고 프로그래밍 기법은 자유로이 변경될 수 있다. 당업자에게 자명한 모든 다른 변경, 교체이나 변형물은 다음의 청구항에 기재되었는지 여부에 무관하게 본 발명의 범위에 속한다고 판단하여야 한다. 의심스러운 경우를 방지하게 위하여, 본 명세서에 기재된 모든 신규한 내용과 그 조합에 대한 권리의 보호를 구하는 바이다.
본 발명은 복수의 운영체제를 한 컴퓨터 내에서 운용하는 데에 있어서 시스템 자원을 절약하고, 통상적으로 시판되는 운영체제 프로그램에 제한적인 변화를 가하는 것만으로도 설치 가능하고 운영체제의 새 버전을 다중 운영체제 방식에서 작동하게끔 고치는 수고가 거의 들지 않는 컴퓨터의 다중 운영체제 운용 방식을 제공한다.

Claims (36)

  1. 상대적으로 높은 우선 순위를 가지는 제1운영체제를 선택하는 단계;
    상대적으로 낮은 우선 순위를 가지는 제2운영체제를 적어도 하나 이상 선택하는 단계;
    미리 예정된 조건 하에서 상기 운영체제들 사이를 스위칭하도록 정해진 공통 프로그램을 제공하는 단계; 그리고
    상기 제1운영체제와 제2운영체제가 상기 공통 프로그램에 의하여 제어될 수 있도록 조절하는 단계;
    를 포함하는 복수의 다른 운영체제가 동시에 같은 컴퓨터에서 수행될 수 있도록 하는 방법.
  2. 제1항에 있어서, 제1 메모리 문맥과 제2 메모리 문맥 각각에 관련이 있는 상기 제1운영체제와 제2운영체제; 그리고
    제1 메모리 문맥과 상기 운영 체제 사이를 스위칭할 때, 현재 메모리 문맥과 제1, 제2 내지 제3 메모리 문맥을 스위칭하는 것을 포함하는 방법과 관련이 있는 상기 공통 프로그램;을 포함하는 방법
  3. 제2항에 있어서, 제1운영 체제로 스위칭할 때 또는 제1운영 체제로부터 스위칭할 때, 상기 현재 메모리 문맥을 제1 메모리 문맥으로 스위칭하는 단계가 추가되는 방법.
  4. 제2항 또는 제3항에 있어서, 상기 제1운영체제에 의해 상기 공통 프로그램을 불러내고, 상기 제1 메모리 문맥에서 상기 공통 프로그램의 수행을 시작하는 단계가 추가되는 방법.
  5. 제2항 또는 제3항에 있어서, 상기 공통 프로그램에 의해 상기 제1운영체제를 접수하고, 상기 제1 메모리 문맥에서 상기 공통 프로그램의 수행을 시작하는 단계가 추가되는 방법.
  6. 제2항에 있어서, 상기 제2운영체제로부터 스위칭할 때, 상기 현재 메모리 문맥을 상기 제3 메모리 문맥으로 스위칭하는 단계가 추가되는 방법.
  7. 제6항에 있어서, 상기 현재 메모리 문맥이 상기 제1 메모리 문맥인 상기 제2 운영체제에 의해 상기 공통 프로그램을 불러내는 단계가 추가되는 방법.
  8. 제6항에 있어서, 상기 현재 메모리 문맥이 상기 제3 메모리 문맥인 상기 공통 프로그램에 의해 상기 제2운영체제를 접수하는 단계가 추가되는 방법.
  9. 제8항에 있어서, 제2운영체제는 트랩 불러내기에 의해 상기 공통 프로그램을 불러내는 방법.
  10. 제1항 내지 제9항 중 어느 한 항에 있어서, 상기 제1운영체제는 실시간 운영체제인 방법.
  11. 제1항 내지 제10항 중 어느 한 항에 있어서, 상기 제2운영체제는 비실시간 범용 운영체제인 방법.
  12. 제1항 내지 제11항 중 어느 한 항에 있어서, 상기 제2운영체제는 리눅스 또 는 그 변형물인 방법.
  13. 제1항 내지 제12항 중 어느 한 항에 있어서, 상기 공통 프로그램은 상기 운영체제 사이를 스위칭하는데 필요한 처리장치의 상태를 저장하고 그 저장된 버전으로부터 복원하도록 정해진 방법.
  14. 제1항 내지 제13항 중 어느 한 항에 있어서, 상기 제2운영체제의 프로세서 예외 상황은 상기 공통 프로그램이 가상 방식으로 처리하는 방법.
  15. 제1항 내지 제14항 중 어느 한 항에 있어서, 상기 공통 프로그램은 몇 가지의 프로세서 예외를 인터셉트하고 또한 그 예외 서비스를 제공하기 위하여 상기 제1운영체제의 예외 처리 루틴을 호출하도록 정하여진 방법.
  16. 제1항 내지 제15항 중 어느 한 항에 있어서, 상기 제2운영체제의 프로세서 예외는 가상 예외로 고지되는 방법.
  17. 제16항에 있어서, 상기 공통 프로그램은 미결인 상기 가상 예외에 대응하는 제2운영체제의 예외 처리 루틴을 호출하도록 정하여진 방법.
  18. 제1항 내지 제17항 중 어느 한 항에 있어서, 상기 운영체제들 각각이 독점적으로 작동할 수 있는 독립된 메모리 공간을 각각 제공하는 단계가 추가되는 방법.
  19. 제1항 내지 제18항 중 어느 한 항에 있어서, 상기 운영체제들 각각이 상기 컴퓨터에서 독점적으로 접근할 수 있는 제1입력장치 또는 제1출력장치를 각각 제공하는 단계가 추가되는 방법.
  20. 제1항 내지 제19항 중 어느 한 항에 있어서, 상기 운영체제들 각각이 상기 제1입력장치 또는 제1출력장치를 접근할 때 원시 루틴을 실질적 변화 없이 사용하는 방법.
  21. 제1항 내지 제20항 중 어느 한 항에 있어서, 상기 운영체제 각각이 접근을 공유하는 제2입력장치 또는 제2출력장치를 제공하는 단계가 추가되는 방법.
  22. 제21항에 있어서, 모든 운영체제는 제1운영체제의 상기 루틴을 사용하여 상기 제2입력장치 또는 제2출력장치를 접근하는 방법.
  23. 제1항 내지 제22항 중 어느 한 항에 있어서, 상기 제2운영체제를 상기 제1운영체제나 공통 프로그램의 인터럽트 없이 재시작하기 위한 재시작 루틴을 제공하는 단계가 추가되는 방법.
  24. 제21항에 있어서, 상기 제2 장치는 하나의 코-프로세서를 구비하고 상기 제1운영체제와 상기 제2운영체제 (또는 그 반대)의 스위칭이 일어날 때 상기 코-프로세서의 상태가 변하지 않음으로써 만약 상기 운영체제가 상기 코-프로세서로의 간섭 접근이 없이 스위칭되어 돌아오면 그 실행은 중단되지 않고 완료할 수 있는 방법
  25. 제1항에 있어서, 하나 또는 그 이상의 원 주소 테이블은 운영 시스템에 의해 사용된 컴퓨터에 의하여 제공되고; 공통 프로그램은 상기 원 주소 테이블에 접근하고, 메모리 내에서 상기 원 주소 테이블과 동일한 구조를 가지는 운영체제 각각에 의해 사용되는 개개의 운영체제에 의하여 테이블 당 하나씩 복제된 테이블의 다수를 제공하며; 그리고 상기 운영체제는 상기 복재된 테이블을 호출하는 루틴과 함께 상기 원 주소 테이블을 쓰는 명령어를 대체하기 위해 수정되는; 방법
  26. 제1항 내지 제25항 중 어느 한 항에 있어서, 상기 운영체제들과 공통 프로그램은 하나의 프로그램 코드로 통합된 구성으로 갖춘 방법.
  27. 제1항 내지 제26항 중 어느 한 항에 있어서, 상기 운영체제들과 공통 프로그램은 컴퓨터 장치의 영구 메모리상에 내장되는 구성이 추가된 방법.
  28. 제1항 내지 제27항 중 어느 한 항에 있어서, 상기 운영체제 각각에 상기 공통 프로그램으로 제어권을 넘기는 유휴 루틴을 제공하는 방법.
  29. 제28항에 있어서, 상기 유휴 루틴은 프로세서 정지 명령을 대체하는 방법.
  30. 제1항 내지 제29항 중 어느 한 항의 상기 방법에 기재된 상기 것들을 수행하기 위한 코드를 포함하는 개발 키트 컴퓨터 프로그램 결과.
  31. 제30항에 따라 통합된 코드를 포함하는 컴퓨터 프로그램 결과.
  32. 중앙처리장치 메모리 장치 및 입/출력 장치들을 포함하며, 영구 메모리 그 내에 제31항에 따라 내장된 프로그램들을 저장시키는 내장 컴퓨터 시스템.
  33. 상대적으로 높은 우선 순위를 가지는 제1운영체제;
    상대적으로 낮은 우선 순위를 가지는 제2운영체제; 그리고,
    미리 예정된 조건 하에서 상기 운영체제 사이를 스위칭함으로써 상기 운영체제들을 동시에 작동하도록 마련된 공통 프로그램;
    을 포함하고, 컴퓨터 코드를 실행시키며 중앙처리장치, 메모리 장치 및 입/출력장치를 포함하는 컴퓨터 시스템.
  34. 제33항에 있어서, 제1항 내지 제29항 중 어느 한 항의 방법을 이용하여 상기 제1 운영체제와 제2 운영체제를 동시에 작동하도록 마련된 컴퓨터 시스템.
  35. 하나의 프로세서와 하나의 메모리를 구비하는 하나의 컴퓨터 시스템은 그 위에 제1 그리고 제2 메모리 문맥 각각에서 제1 및 제2 운영체제를 작동하도록 하는 컴퓨터 코드가 실행 가능하고, 상기 제1 또는 하나의 제3 메모리 문맥 안에서 사용 가능한 하나의 공통 프로그램이, 상기 공통 프로그램이 작동하는 상기 메모리 문맥이 상기 스위칭 작동에 의존하는 상기 제1 운영체제와 상기 제2운영체제 사이에서 스위칭하는 컴퓨터 시스템.
  36. 상기 컴퓨터가 감소된 명령 설정 구조를 포함하는 제1항 내지 제35항 중 어느 한 항의 상기 시스템, 결과 또는 방법.
KR1020067008560A 2003-09-30 2004-09-30 운영체제 Withdrawn KR20070005917A (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP03292414 2003-09-30
EP03292414.4 2003-09-30

Publications (1)

Publication Number Publication Date
KR20070005917A true KR20070005917A (ko) 2007-01-10

Family

ID=37779352

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020067008560A Withdrawn KR20070005917A (ko) 2003-09-30 2004-09-30 운영체제

Country Status (4)

Country Link
US (1) US8024742B2 (ko)
JP (1) JP2007509387A (ko)
KR (1) KR20070005917A (ko)
CN (1) CN1922576A (ko)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130095142A (ko) * 2012-02-17 2013-08-27 인포뱅크 주식회사 프로그램 실행 방법 및 장치와 이를 위한 기록매체
KR20150050739A (ko) * 2013-10-31 2015-05-11 삼성에스디에스 주식회사 요청 메시지 스케줄링 장치 및 방법과 이를 이용한 기록 매체
KR101535792B1 (ko) * 2013-07-18 2015-07-10 포항공과대학교 산학협력단 운영체제 구성 장치 및 방법
KR20170055180A (ko) * 2015-11-11 2017-05-19 삼성전자주식회사 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법
KR20210045373A (ko) * 2021-04-06 2021-04-26 주식회사 틴텍 인쇄장치에 이용되는 이종 운영체제간의 정보 전달 방법

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8612992B2 (en) * 2003-04-09 2013-12-17 Jaluna Sa Operating systems
ATE409904T1 (de) * 2003-04-09 2008-10-15 Jaluna Sa Betriebssysteme
EP1503286B1 (en) * 2003-07-30 2014-09-03 Jaluna SA Multiple operating system networking
US7490318B2 (en) * 2005-02-25 2009-02-10 Inventec Corporation Computer platform operating system compatibility management method and system
JP4850830B2 (ja) * 2005-06-01 2012-01-11 パナソニック株式会社 コンピュータシステム及びプログラム生成装置
US20070156786A1 (en) * 2005-12-22 2007-07-05 International Business Machines Corporation Method and apparatus for managing event logs for processes in a digital data processing system
US7950020B2 (en) * 2006-03-16 2011-05-24 Ntt Docomo, Inc. Secure operating system switching
US20080222659A1 (en) * 2007-03-09 2008-09-11 Microsoft Corporation Abstracting operating environment from operating system
US9454384B2 (en) * 2007-07-05 2016-09-27 Microsoft Technology Licensing, Llc Custom operating system via a web-service
CA2699564C (en) * 2007-09-20 2014-07-08 C&S Operations, Inc. Computer system with tunneling
US7719876B2 (en) 2008-07-31 2010-05-18 Unity Semiconductor Corporation Preservation circuit and methods to maintain values representing data in one or more layers of memory
JP4985662B2 (ja) * 2009-01-22 2012-07-25 株式会社デンソー プログラム、及び制御装置
US20100265938A1 (en) * 2009-04-16 2010-10-21 Mitel Networks Corporation Enhanced system operation by virtualization
US8868899B2 (en) * 2009-07-20 2014-10-21 Motorola Mobility Llc System and method for switching between environments in a multi-environment operating system
US8381040B2 (en) * 2009-10-26 2013-02-19 International Business Machines Corporation Relocatable interrupt handler for test generation and execution
JP5875193B2 (ja) * 2010-01-13 2016-03-02 マーベル・イスラエル・(エム・アイ・エス・エル)・リミテッドMarvell Israel (M.I.S.L.) Ltd. メディア処理のためのハードウェア仮想化
US9010641B2 (en) 2010-12-07 2015-04-21 Hand Held Products, Inc. Multiple platform support system and method
US10417018B2 (en) 2011-05-27 2019-09-17 Microsoft Technology Licensing, Llc Navigation of immersive and desktop shells
US8924885B2 (en) 2011-05-27 2014-12-30 Microsoft Corporation Desktop as immersive application
US9843665B2 (en) 2011-05-27 2017-12-12 Microsoft Technology Licensing, Llc Display of immersive and desktop shells
JP5729146B2 (ja) * 2011-06-03 2015-06-03 富士通株式会社 情報端末装置、情報端末装置の制御方法およびプログラム
JP5729266B2 (ja) * 2011-11-15 2015-06-03 富士通株式会社 情報処理装置、情報処理装置の制御方法、及び情報処理装置の制御プログラム
JP5422687B2 (ja) * 2012-02-20 2014-02-19 京セラドキュメントソリューションズ株式会社 通信処理装置および画像形成装置
EP2819023A4 (en) * 2012-02-23 2016-06-08 Mitsubishi Electric Corp COMPUTER DEVICE, ACCESS MANAGEMENT METHOD, AND ACCESS MANAGEMENT PROGRAM
US8918799B2 (en) 2012-03-30 2014-12-23 International Business Machines Corporation Method to utilize cores in different operating system partitions
US8789046B2 (en) * 2012-03-30 2014-07-22 International Business Machines Corporation Method to embed a light-weight kernel in a full-weight kernel to provide a heterogeneous execution environment
CN102831006B (zh) * 2012-07-25 2017-04-12 北京奇虎科技有限公司 虚拟机实现方法与虚拟机
US9477505B2 (en) 2012-08-14 2016-10-25 Oracle International Corporation Method for reducing the overhead associated with a virtual machine exit when handling instructions related to descriptor tables
US9842091B2 (en) * 2013-03-15 2017-12-12 Google Llc Switching to and from native web applications
US9851982B2 (en) * 2014-02-28 2017-12-26 Tyco Fire & Security Gmbh Emergency video camera system
US20150287295A1 (en) 2014-04-02 2015-10-08 Tyco Fire & Security Gmbh Smart Emergency Exit Signs
CN105204931B (zh) * 2014-06-11 2019-03-15 联发科技(新加坡)私人有限公司 低功耗可穿戴设备及其多操作系统切换、通信及管理方法
US10775875B2 (en) * 2014-06-11 2020-09-15 Mediatek Singapore Pte. Ltd. Devices and methods for switching and communication among multiple operating systems and application management methods thereof
CN105700940B (zh) * 2014-11-25 2019-05-31 深圳市中兴微电子技术有限公司 一种调度器及调度器的动态复用方法
US9652215B2 (en) 2014-12-30 2017-05-16 Microsoft Technology Licensing, Llc Application installation/uninstallation across multiple systems
JP6471758B2 (ja) * 2015-01-07 2019-02-20 富士通株式会社 タスク切替支援方法、タスク切替支援プログラム、及び情報処理装置
CN105577904B (zh) * 2015-03-27 2019-04-12 酷派软件技术(深圳)有限公司 一种文件共享方法及移动终端
US10169105B2 (en) 2015-07-30 2019-01-01 Qualcomm Incorporated Method for simplified task-based runtime for efficient parallel computing
CN109117253B (zh) * 2017-06-26 2022-05-24 阿里巴巴集团控股有限公司 一种微内核调度的方法和装置
CN108932160A (zh) * 2017-10-10 2018-12-04 北京猎户星空科技有限公司 多操作系统控制方法、装置、电子设备和计算机存储介质
CN108153559A (zh) * 2017-12-08 2018-06-12 芯海科技(深圳)股份有限公司 一种不影响mcu工作实时性的快速重构架构
CN109947539A (zh) * 2017-12-20 2019-06-28 广州中国科学院先进技术研究所 一种机器人控制器
FR3089316B1 (fr) * 2018-11-30 2020-10-30 Thales Sa Procédé et dispositif de surveillance d’application(s) logicielle(s) avec période temporelle tampon précédant une section réservée pour un ensemble de ressource(s) partagée(s), programme d’ordinateur et système avionique associés
CN113127069B (zh) * 2019-12-31 2023-08-22 成都鼎桥通信技术有限公司 基于双系统的位置服务管理方法、装置和终端设备
CN112559136A (zh) * 2020-12-24 2021-03-26 科东(广州)软件科技有限公司 一种计算机中断投递的方法及装置

Family Cites Families (52)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR2580096B1 (ko) 1985-04-04 1988-08-19 Nec Corp
US4747040A (en) 1985-10-09 1988-05-24 American Telephone & Telegraph Company Dual operating system computer
JP2629278B2 (ja) 1988-06-30 1997-07-09 株式会社日立製作所 仮想計算機システム
DE3831048A1 (de) 1988-09-12 1990-03-15 Nixdorf Computer Ag Betriebsprogramm fuer eine datenverarbeitungsanlage
US5144692A (en) 1989-05-17 1992-09-01 International Business Machines Corporation System for controlling access by first system to portion of main memory dedicated exclusively to second system to facilitate input/output processing via first system
JPH04200013A (ja) * 1990-11-29 1992-07-21 Hitachi Ltd 論理回路
US5355490A (en) 1991-06-14 1994-10-11 Toshiba America Information Systems, Inc. System and method for saving the state for advanced microprocessor operating modes
US5596755A (en) 1992-11-03 1997-01-21 Microsoft Corporation Mechanism for using common code to handle hardware interrupts in multiple processor modes
US5530858A (en) 1993-04-01 1996-06-25 Intel Corporation Method and apparatus for background processing for PCMCIA card services
US6684261B1 (en) 1993-07-19 2004-01-27 Object Technology Licensing Corporation Object-oriented operating system
US5379432A (en) 1993-07-19 1995-01-03 Taligent, Inc. Object-oriented interface for a procedural operating system
US5884077A (en) 1994-08-31 1999-03-16 Canon Kabushiki Kaisha Information processing system and method in which computer with high load borrows processor of computer with low load to execute process
US5903752A (en) 1994-10-13 1999-05-11 Intel Corporation Method and apparatus for embedding a real-time multi-tasking kernel in a non-real-time operating system
US5721922A (en) 1994-10-13 1998-02-24 Intel Corporation Embedding a real-time multi-tasking kernel in a non-real-time operating system
US5740438A (en) 1995-03-31 1998-04-14 International Business Machines Corporation Methods and system for network communications of multiple partitions
US5812823A (en) * 1996-01-02 1998-09-22 International Business Machines Corporation Method and system for performing an emulation context save and restore that is transparent to the operating system
US6535929B1 (en) 1996-07-02 2003-03-18 Sun Microsystems, Inc. Universal communication mechanism for applications running in a multitasking environment
US5995745A (en) 1996-12-23 1999-11-30 Yodaiken; Victor J. Adding real-time support to general purpose operating systems
US6199096B1 (en) 1997-03-14 2001-03-06 Efusion, Inc. Method and apparatus for synchronizing information browsing among multiple systems
US6269409B1 (en) 1997-09-02 2001-07-31 Lsi Logic Corporation Method and apparatus for concurrent execution of operating systems
US6772419B1 (en) * 1997-09-12 2004-08-03 Hitachi, Ltd. Multi OS configuration system having an interrupt process program executes independently of operation of the multi OS
FI108478B (fi) 1998-01-21 2002-01-31 Nokia Corp Sulautettu jõrjestelmõ
US6134653A (en) * 1998-04-22 2000-10-17 Transwitch Corp. RISC processor architecture with high performance context switching in which one context can be loaded by a co-processor while another context is being accessed by an arithmetic logic unit
US6496847B1 (en) * 1998-05-15 2002-12-17 Vmware, Inc. System and method for virtualizing computer systems
FR2793906B1 (fr) 1999-05-19 2001-08-10 Bull Sa Systeme et procede de gestion d'attributs dans un environnement oriente objet
JP3659062B2 (ja) 1999-05-21 2005-06-15 株式会社日立製作所 計算機システム
JP2000347883A (ja) * 1999-06-03 2000-12-15 Matsushita Electric Ind Co Ltd 仮想計算機装置
US6920633B1 (en) 2000-01-14 2005-07-19 Microsoft Corporation Cross-process common system resource data sharing
US6763327B1 (en) * 2000-02-17 2004-07-13 Tensilica, Inc. Abstraction of configurable processor functionality for operating systems portability
US7036106B1 (en) * 2000-02-17 2006-04-25 Tensilica, Inc. Automated processor generation system for designing a configurable processor and method for the same
JP2001282558A (ja) * 2000-03-30 2001-10-12 Hitachi Ltd マルチオペレーティング計算機システム
US6715016B1 (en) 2000-06-01 2004-03-30 Hitachi, Ltd. Multiple operating system control method
EP1162536A1 (en) 2000-06-09 2001-12-12 Hitachi, Ltd. Multiple operating system control method
KR20020092969A (ko) * 2000-06-20 2002-12-12 가부시끼가이샤 히다치 세이사꾸쇼 차량의 주행제어장치
US6868507B1 (en) 2000-11-07 2005-03-15 Intel Corporation Operating system independent
US20020078339A1 (en) 2000-12-15 2002-06-20 Shen Hung-Ju Booting system and booting method for an assistant operation system
US20020161961A1 (en) 2001-01-17 2002-10-31 Ajile Systems, Inc. Multiple virtual machine environment management system
US6789156B1 (en) * 2001-05-22 2004-09-07 Vmware, Inc. Content-based, transparent sharing of memory units
JP2003036174A (ja) 2001-07-25 2003-02-07 Hitachi Ltd 車載端末装置
US7191440B2 (en) 2001-08-15 2007-03-13 Intel Corporation Tracking operating system process and thread execution and virtual machine execution in hardware or in a virtual machine monitor
US7356677B1 (en) 2001-10-19 2008-04-08 Flash Vos, Inc. Computer system capable of fast switching between multiple operating systems and applications
AU2002351911A1 (en) * 2001-11-07 2003-05-19 Harald Kuck Providing isolation through process attachable virtual machines
US6725289B1 (en) * 2002-04-17 2004-04-20 Vmware, Inc. Transparent address remapping for high-speed I/O
US6920587B2 (en) 2002-04-25 2005-07-19 International Business Machines Corporation Handling multiple operating system capabilities in a logical partition data processing system
KR100421144B1 (ko) 2002-05-24 2004-03-04 삼성전자주식회사 미디어 게이트웨이 콘트롤 프로토콜방식의 보이스 오버인터넷 프로토콜 호 서비스를 위한 헤드 엔드 장치
US7296267B2 (en) * 2002-07-12 2007-11-13 Intel Corporation System and method for binding virtual machines to hardware contexts
US6782424B2 (en) 2002-08-23 2004-08-24 Finite State Machine Labs, Inc. System, method and computer program product for monitoring and controlling network connections from a supervisory operating system
US7089377B1 (en) * 2002-09-06 2006-08-08 Vmware, Inc. Virtualization system for computers with a region-based memory architecture
US8214531B2 (en) 2002-10-24 2012-07-03 Emulex Design & Manufacturing Corporation Network configuration synchronization for hardware accelerated network protocol
ATE409904T1 (de) 2003-04-09 2008-10-15 Jaluna Sa Betriebssysteme
US8612992B2 (en) 2003-04-09 2013-12-17 Jaluna Sa Operating systems
EP1503286B1 (en) 2003-07-30 2014-09-03 Jaluna SA Multiple operating system networking

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20130095142A (ko) * 2012-02-17 2013-08-27 인포뱅크 주식회사 프로그램 실행 방법 및 장치와 이를 위한 기록매체
KR101535792B1 (ko) * 2013-07-18 2015-07-10 포항공과대학교 산학협력단 운영체제 구성 장치 및 방법
KR20150050739A (ko) * 2013-10-31 2015-05-11 삼성에스디에스 주식회사 요청 메시지 스케줄링 장치 및 방법과 이를 이용한 기록 매체
KR20170055180A (ko) * 2015-11-11 2017-05-19 삼성전자주식회사 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법
KR20210045373A (ko) * 2021-04-06 2021-04-26 주식회사 틴텍 인쇄장치에 이용되는 이종 운영체제간의 정보 전달 방법

Also Published As

Publication number Publication date
US20070078891A1 (en) 2007-04-05
JP2007509387A (ja) 2007-04-12
US8024742B2 (en) 2011-09-20
CN1922576A (zh) 2007-02-28

Similar Documents

Publication Publication Date Title
KR20070005917A (ko) 운영체제
EP2296089B1 (en) Operating systems
US7434224B2 (en) Plural operating systems having interrupts for all operating systems processed by the highest priority operating system
US8612992B2 (en) Operating systems
KR20070003765A (ko) 운영체제
US20050251803A1 (en) Method of performing kernel task upon initial execution of process at user level
US20050246708A1 (en) Method of assigning virtual process identifier to process within process domain
EP1673697B1 (en) Operating systems
Polakovic et al. Building reconfigurable component-based OS with THINK
KR20060023956A (ko) 운영체제
EP1673693B1 (en) Operating systems
Biemueller Hardware-supported virtualization for the l4 microkernel
Ludwig et al. Porting openBSD to fiasco
Yang In Place Migration by Using Pre-Virtualization
Stoess et al. Unmodified device driver reuse and improved system dependability via virtual machines
Golm The structure of a type safe operating system
LeVasseur Device driver reuse via virtual machines.
Blattmann Universität Karlsruhe (TH)
林宗翰 Addressing Hybrid OS Environment Issues in the Embedded Virtualization Multicore Platform
Maheshwari Extensible Operating Systems

Legal Events

Date Code Title Description
PA0105 International application

Patent event date: 20060502

Patent event code: PA01051R01D

Comment text: International Patent Application

PG1501 Laying open of application
PC1203 Withdrawal of no request for examination
WITN Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid