KR20060023956A - 운영체제 - Google Patents

운영체제 Download PDF

Info

Publication number
KR20060023956A
KR20060023956A KR1020057019290A KR20057019290A KR20060023956A KR 20060023956 A KR20060023956 A KR 20060023956A KR 1020057019290 A KR1020057019290 A KR 1020057019290A KR 20057019290 A KR20057019290 A KR 20057019290A KR 20060023956 A KR20060023956 A KR 20060023956A
Authority
KR
South Korea
Prior art keywords
operating system
operating
common program
exception
virtual
Prior art date
Application number
KR1020057019290A
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
Priority claimed from EP03290894A external-priority patent/EP1467282B1/en
Application filed by 쟈루나 에스에이 filed Critical 쟈루나 에스에이
Publication of KR20060023956A publication Critical patent/KR20060023956A/ko

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
    • 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
    • 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
    • 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
    • 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
    • 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)
  • Hardware Redundancy (AREA)

Abstract

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

Description

운영체제{Operating Systems}
본 발명은 운영체제에 관한 것이다. 구체적으로는 본 발명은 복수의 운영체제가 동시에 수행되도록 하기 위한 시스템, 방법, 컴퓨터 프로그램에 관한 발명이다.
일부 컴퓨터 프로그램에서는 프로그램 단계들이 정해진 시간 내에 혹은 정해진 시각에 실행되는 것이 매우 중요하다. 그러한 프로그램의 예로서 휴대전화, 사설 전화교환기(PBX), 휴대전화 기지국을 제어하는 프로그램들을 들 수 있다. 전형적으로는 이 프로그램들이 외부 이벤트나 상태 변화에 일관된 방식으로, 이벤트가 일어난 그 시각에 또는 그로부터 일정한 시간 내에 반응하여야만 한다. 이를 가리켜 "실시간"으로 작동한다고 일컫는다.
다른 수많은 프로그램의 경우에는 그러나, 프로그램을 실행하는데 드는 시간이 그리 중요하지 않다. 이는 대부분의 컴퓨터 프로그램에 해당되는데, 스프레드시트, 문서 편집기, 급여 관리, 그리고 일반적인 보고·분석용 프로그램이 이에 속 한다. 한편 그러한 프로그램 실행에 걸린 정확한 시간은 중요하지 않을지라도, 대부분의 경우 사용자는 가능한 한 더 빠른 실행 속도를 선호한다.
응용 프로그램(applications program)은 그가 실행되는 컴퓨터 내에서 그 컴퓨터와 운영체제를 통하여 상호작용한다. 응용 프로그램용 인터페이스(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")" 운영체제를 마련하여 사용자가 운영체제를 택일하여 운용하는 것도 가능하지만, "기존 사용" 프로그램을 실시간 프로그램과 동시에 실행하는 것이 바람직한 경우도 많이 있다. 예를 들어 통신망 기반 장비(network infrastructure equipment), 제3세대 휴대전화와 다른 첨단 전화기, 첨단 전자 게임기 등은 실시간 응용 프로그램(예를 들어 게임용 그래픽)과 비실시간 응용 프로그램(게임 내려받기)이 모두 필요할 수 있다.
미국 특허 5903752호와 5721922호에서는 실시간 다중 처리 커널(multi-tasking kernel)을 비실시간 운영체제(윈도우즈와 같은)의 인터럽트 처리 환경에 제공함으로써 실시간 환경을 비실시간 운영체제에 도입하려는 시도를 하였다.
널리 사용된 한 가지 방식은 "에뮬레이션"이다. 전형적인 에뮬레이션 프로그램은 실시간 운영체제에서 실행되도록 작성되고, 범용 운영체제에서 작동하도록 짜여진 다른 프로그램의 각 명령을 해석한 뒤 그에 대응하는 명령들을 실시간 운영체제하에서 수행한다. 그러나 한 명령이 언제나 다수의 명령으로 대체되기 때문에 에뮬레이션은 컴퓨터에 큰 부담을 주고, 수행 속도를 떨어뜨린다. 가상 머신(예를 들어 JavaTM 가상 머신)을 제공하는 방식에서도 비슷한 문제가 일어난다. 가상 머신을 장착한 예로서 유럽 특허 EP 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)인데, 이는 http://www.aero.polimi.it/~rtai/applications를 보면 된다.
유럽 특허 1054332호는 "교환 단위"("switching unit" 완전한 이해할 만큼 충분하게 설명되지 않았음)가 실시간과 범용 운영체제를 실행하는 시스템을 기술한다. 하드웨어 인터럽트는 공통 인터럽트 처리기가 처리하고, 몇몇 실시예에서는 실시간 운영체제가 담당하는데 실시간 운영체제는 이어서 보조(secondary) 운영체제 루틴이 처리할 소프트웨어 인터럽트를 우선 순위를 낮게 부여하여 발생시킨다.
본 발명의 목적은 복수의 운영체제를 다른 용도로 설계된 경우에까지도 동시에 실행하기 위한 개선된 시스템, 방법 및 컴퓨터 프로그램을 제공하는 데에 있다. 특히 본 발명은 운영체제 중 하나(예를 들어 실시간 운영체제)가 방해받지 않고 작업을 수행하고 다른 하나(예를 들어 범용 운영체제)는 컴퓨터의 나머지 자원을 최대한 잘 활용하며 작업을 수행하도록 하는 것을 꾀한다.
따라서 본 발명의 일측면은 복수의 운영체제가 약간 설계 변경을 받고 거기에 공통 프로그램이 주어지되, 그 공통 프로그램에 의하여 그들 사이의 스케줄링 작업이 수행되고, 그들 중 한 운영체제("주운영체제" 또는 "핵심 운영체제")가 다른 운영체제들("보조"나 "비핵심" 운영체제)에 대하여 특혜를 받는 시스템을 제공한다. 더 바람직하게는 본 발명은 하드웨어를 핵심 운영체제에 특혜적으로 할당하며, 핵심 운영체제가 접근(access)하는데 방해가 되는 보조 운영체제(들)의 접근을 인정하지 않는다. 본 발명은 더 바람직하게는 핵심 운영체제 드라이버를 사용하여 공유 자원(shared resources)에 접근하는데, 그것은 설령 보조 운영체제가 그러한 접근을 요하더라도 마찬가지이다. 그러나 미국 특허 5995745에서와 같이 핵심 운영체제가 보조 운영체제를 "실행"하는 것은 절대로 아니다. 각 체제는 실행 중에 상대 운영체제를 무시하며 오로지 공통 프로그램(선행기술의 나노커널에 해당)과만 통신하는데 이 프로그램은 핵심 운영체제의 드라이버에 대한 접근을 중개한다.
보조 운영체제들은 인터럽트를 금지하지 못하도록 설계 변경되며 그들의 인터럽트 서비스 루틴은 인터럽트 발생을 가리키는 메시지에 반응하도록 설계 변경되는 것이 바람직하다. 공통 프로그램은 모든 하드웨어 예외(exception)를 주운영체제의 인터럽트 서비스 루틴에 넘김으로써 처리하고, 하드웨어 인터럽트의 대상이 보조 운영체제였던 경우에는 인터럽트 메시지나 고지(notification)를 생성한다. 공통 프로그램의 스케줄링에 따라 보조 운영체제가 할당된 다음 차례에 위 메시지나 고지는 그로 넘겨지고 공통 프로그램은 인터럽트 서비스를 위한 루틴을 호출한다.
따라서 인터럽트 발생시에 보조 운영체제는 주운영체제(혹은 일반적으로 보조 운영체제 중 중요도가 더 높은 것)를 어떤 방식으로도 접수할 수 없는데, 이는 모든 인터럽트가 먼저 주운영체제에 의하여 처리되고 보조 운영체제에 대한 인터럽트는 주운영체제가 작업 수행을 마치고 보조 운영체제에 스케줄링에 따른 차례가 왔을 때에만 인터럽트를 보조 운영체제에 고지하기 때문이다.
이러한 인터럽트 처리는 따라서 주운영체제에 중요한 작업이 없을 때까지 미뤄진다. 그러나 결국 인터럽트 처리가 실행될 때는 보조 운영체제의 루틴들이 실질적으로 거의 변경되지 않은 채로 작동하여 그 결과 그 거동(behaviour)은 보조 운영체제로서 예측되는 바(처리가 연기된 것을 제외하고)대로 움직인다.
시스템 하드웨어
본 운영체제를 적용할 수 있는 컴퓨터(100)는 인텔社 펜티엄 4나 모토롤라社파워 PC(실시예에서는 양쪽 모두 구현하였음)와 같은 중앙 처리 장치(CPU, 102), 그와 연결된 읽기 전용 메모리(ROM) 칩(106), CPU와 ROM을 잇는 시스템 버스(104, 제어·데이터·어드레스 버스로 이루어진다), 하나 또는 여러 개의 램(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)에 공간을 할당한 다음, 각 프로그램을 그 할당된 메모리 공간에 저장한다.
응용 프로그램의 작동시, 운영체제의 스케줄러 부분은 상이한 응용 프로그램들 사이의 CPU 사용량을 분배하여, 스케줄링 방침에 따라 각각이 프로세서 시간을 나눠 가질 수 있게끔 한다. 스케줄러는 또한 잘 안 쓰이는 응용 프로그램이나 데이터를 "밖으로 치환"(swapping out, 즉 그들을 RAM(108)으로부터 제거하여 메모리 공간을 비우고, 이들을 디스크에 저장)함으로써 메모리 자원의 사용을 관리한다.
마지막으로 응용 프로그램은 응용 프로그램용 인터페이스(API)를 구성하는 루틴을 호출하여 입력과 출력 등의 기능을 수행하고, 운영체제의 인터럽트 처리 루틴은 인터럽트와 이벤트들에 응답한다.
도 1은 본 발명이 실행될 수 있는 컴퓨터의 구성 요소를 나타내는 블록 그림이다.
도 2a는 선행기술의 소프트웨어 배치를 도시하는 그림이다.
도 2b는 본 실시예에 따른 소프트웨어의 배치를 도시하는, 2a에 대응하는 그림이다.
도 3은 도 1의 컴퓨터를 위한 도 2b의 소프트웨어를 작성하는 단계를 보여주는 흐름도이다.
도 4는 도 2b의 일부를 이루는 하드웨어 자원 디스패처(dispatcher)의 구성 요소를 보여준다.
도 5는 부팅과 초기화에 사용되는 프로그램을 도시한다.
도 6은 부팅 또는 초기화 과정에 사용되는 시스템 메모리 이미지를 도시한다.
도 7은 주운영체제로부터 한 보조 운영체제로 전이하는 과정을 도시한다.
도 8은 한 보조 운영체제로부터 주운영체제로 전이하는 과정을 도시한다.
도 9a는 본 발명에 따라 서로 다른 운영체제에서 실행되는 응용 프로그램 사이의 통신을 도시한다.
도 9b는 본 발명에 따라 서로 다른 컴퓨터상의 서로 다른 운영체제에서 실행되는 응용 프로그램 사이의 통신을 도시한다.
상기 첨부된 도면을 참조하면서 본 발명의 실시예들을 기술하기로 한다. 이는 어디까지나 예시일 뿐이다.
모범 실시예의 원리 요약
모범 실시예에서 도 1의 컴퓨터(100)에 사용될 각 운영체제(201, 202)에는 약간의 설계 변경이 가해지고 낮은 수준의 새 프로그램(400, 여기서 "하드웨어 자원 디스패처"로 명명한다, 비록 운영체제의 커널이 아니지만 때때로 "나노커널"로 불리기도 한다)이 신설된다. 하드웨어 자원 디스패처(400)는 CPU(102)와 상호작용을 하므로 CPU의 특정 형태에 맞춤식으로 되어 있다. 또한 곧 밝힐 명백한 이유에 따라 설계 변경되는 운영체제(201, 202)의 버전 역시 하드웨어에 따라 맞추게 된 다.
하드웨어 자원 디스패처(400)는 그 자체로는 운영체제가 아니다. 디스패체는 응용 프로그램과는 전혀 상호작용하지 않으며, 매우 제한된 기능을 가지고 있다. 디스패처는 비록 대부분의 계산 작업(processing)을 운영체제에 맡기며 프로세서에서 운영체제의 기계어 코드(native code)를 그대로 수행하지만 디스패처가 협동 작업을 하기 위해서는 운영체제를 변경하여야 하므로 가상 머신이나 에뮬레이터(emulator)도 아니다. 디스패처는 아래의 기초적인 기능을 수행한다.
。복수의 운영체제들 각각을 적재하고 시작한다.
。메모리와 다른 시스템 자원을 각 운영체제에 할당한다.
。서로 다른 운영체제들의 작동에 대한 스케줄링을 한다(즉 그들 사이에 CPU 시간을 분배하고 운영체제 사이에 일어나는 상태 변화를 관리한다)
。운영체제들이 나누어 사용하여야 하는 시스템 장치들에 간접적으로 접근하는 방식인 "가상화 장치(virtualised device)"를 제공한다(장치의 "가상화")
。서로 다른 운영체제상에서 실행되는 응용 프로그램들끼리 통신할 수 있도록 운영체제들 사이에 통신 연결을 제공한다.
실시예에서 운영체제는 같은 대우를 받지 않는다. 대신 운영체제 중 하나를 핵심 운영체제(이것이 실시간 운영체제가 됨)로 삼으며 나머지 운영체제는 "비핵 심" 또는 "보조" 운영체제(이는 리눅스와 같은 범용 운영체제가 됨)가 된다.
하드웨어 자원 디스패처 설계시, 사용가능한 시스템 자원(즉 장치와 메모리)를 기재한 데이터 구조(예를 들어 테이블)가 제공되어, 정적으로 할당(static allocation)할 수 있는 가장 많은 시스템 장치를 운영체제 중 어느 하나나 다른 쪽에 갖추게끔 한다. 예를 들어 병렬 프린터 포트는 범용 운영체제(202)에 정적으로 할당될 수 있고, 이 운영체제는 프린터 출력에 필요한 응용 프로그램을 실행하게 된다. 다른 한편으로 ISDN 디지털 선 어댑터 포트는 통신을 위하여 실시간 운영체제(201)에 영구 할당될 수 있다. 장치를 가능한 한 이렇게 정적으로 할당하는 것은 각 운영체제가 자신의 기존 드라이버를 사용하여 정적으로 할당된 장치를 하드웨어 자원 디스패처를 호출할 필요 없이 접근하는 것이 가능함을 뜻한다. 그러므로 그러한 장치에 접근하는 데에 따른 실행 속도의 저하(가상 머신이나 에뮬레이터와 같이 작동할 경우에 일어날 수 있는)가 없어진다.
반드시 공유되어야 하는 시스템 장치의 경우에 하드웨어 자원 디스패처는 비핵심 운영체제에 의한 장치 사용을 가상화하고 핵심 운영체제에 공급된 드라이버를 사용함으로써 장치에 대한 접근을 수행한다. 마찬가지로 인터럽트 처리에서는 인터럽트가 핵심 운영체제의 인터럽트 루틴으로 넘겨지고, 루틴은 인터럽트를 처리하거나(인터럽트 대상이 핵심 운영체제일 때) 하드웨어 자원 디스패처를 통하여 비핵심 운영체제로 전달된다(인터럽트 대상인 그 운영체제일 때).
부팅시 하드웨어 자원 디스패처를 먼저 적재(loading)하고, 디스패처는 다시 각각의 운영체제들을 미리 예정된 순서, 핵심 운영체제부터 시작해서 차례로 각 보조 운영체제로 가는 순에 따라 적재한다. 핵심 운영체제는 테이블 기재에 따라 필요한 자원을 배분받으며 작동할 수 있는 고정 메모리 공간을 소유하고 있다. 각 보조 운영체제는 다시 남은 자원으로부터 필요한 자원과 메모리 공간을 할당받는다. 따라서 실시예에서는 각 운영체제에 고유의 메모리 공간을 할당하고 장치의 독점적인 정적할당을 통하여 운영체제가 사용하는 자원들은 가능한 최대의 물리적 거리를 서로 두게 되고 필수적으로 공유하여야 하는 장치들만이 공유된다.
작동시에 하드웨어 자원 디스패처의 스케줄러는 핵심 운영체제가 모든 수행 작업을 마칠 때까지 실행되도록 하여 주며, 그 다음에는 차례로 각 비핵심 운영체제로 제어 기능을 넘겨 다음 인터럽트나 이벤트가 발생할 때까지 실행되게 한다. 그러므로 실시예의 시스템은 핵심 운영체제의 작동이 실질적으로 불변(핵심 체제가 자신의 고유한 드라이버를 사용하고 어떠한 인터럽트나 이벤트 처리에 대해서도 가장 먼저 접근할 수 있으므로)하는 다중 운영체제 환경을 가져다 준다. 보조 운영체제들은 남은 프로세서 시간의 한도 내에서 효율적으로 작동할 수 있는데, 이는 대부분의 경우 그들이 고유한 전용 드라이버와 다수의 시스템 장치에 대해 독점적으로 접근할 수 있기 때문이다. 최종적으로 하드웨어 자원 디스패처는 제한된 기능들을 처리할 뿐이므로 그 자체가 하나의 작은 프로그램이어도 되는데, 이에 따라 시스템 자원이 절약된다.
모범 실시예는 또한 만들고 유지하는 데 경제적인데, 이는 이미 특정 컴퓨터(100)에 맞춰진 표준적인 시판 운영체제에 제한적인 변화를 주는 것만으로 족하기 때문이다. 나아가, 운영체제의 변경 사항이 특정한 유형의 컴퓨터(100)와 인터페이스를 이루고 운영체제의 여타 부분과 같이 자주 바뀔 가능성이 적은, 인터럽트 처리나 초기화 시간에서의 컴퓨터 배치(configuration)와 같은 설계특정적(architecture-specific) 파일 처리 관련 문제에 국한되기 때문에 똑같은 운영체제의 새 버전을 다중 운영체제 방식에서 작동하게끔 고쳐 주는데 드는 수고가 거의 없다.
모범 실시예에 대한 자세한 기
이 실시예에서 컴퓨터(100)는 인텔 386계열 프로세서(예를 들어 펜티엄 프로세서)와 모토롤라 파워PC 750(RISC, reduced instruction set computer) 컴퓨터(단계 302)이다. 핵심 운영체제(201)는 C5 운영체제(ChorusOS 체제의 제5세대 공개 소스 버전인 Jaluna-1의 실시간 마이크로커널, 공개 소스로 다음 주소에서 무료로 내려받기, http://www.jaluna.com)이다.
단계 306에서 Chorus운영체제 커널(201)은 다중 운영체제 방식하에서 작동하도록 조절되는데 이는 새로운 플랫폼에 이식하는 일(즉 CPU는 같지만 시스템 장치 들은 다른 새 컴퓨터에서 실행가능하도록 새 보드 지원 패키지(BSP, board support package)를 쓰는 일)과 마찬가지 방식으로 다뤄진다. 부팅과 초기화 순서(initialization sequence)는 실시간 운영체제를, 그 자신이 스스로 시작하지 않고, 하드웨어 자원 디스패처가, 그 운영체제에 할당된 메모리 공간에서, 시작할 수 있도록 조절된다. 초기화 순서의 하드웨어 검색 담계는 핵심 운영체제가 다른 보조 운영체제에 할당된 하드웨어 자원에 접근하지 못하게끔 조절된다. 초기화 순서에서 하드웨어 자원 디스패처를 통하여 정적 하드웨어 할당 테이블 내용을 파악하고 디스패처가 사용 가능한 장치들을 감지하게 된다.
함정 호출(trap call, 2012)은 상태를 감지하고 그에 따른 어떠한 조치를 요구하기 위하여 핵심 운영체제에 추가된다. 여기서 함정 호출이란 컴퓨터로 하여금 현재 맥락(context, 즉 레지스터들의 상태)을 저장하고 새로운 맥락을 적재하도록 하는 호출을 말한다. 가상 메모리 주소지정이 쓰였을 때는 따라서 주소 포인터는 바뀌게 된다. 예를 들어 실시간 운영체제(201)이 종착점에 도달(그리고 프로세서 자원을 사용할 필요가 없어져)한 때는 제어 기능이 다시 하드웨어 자원 디스패처에 되돌려지고, "유휴(idle)" 함정 호출을 발하여 보조 운영체제를 시작할 수 있다. 많은 프로세서들은 "정지(halt)" 명령을 가지고 있다. 몇몇 경우에 감독자 수준의 코드(예를 들어 응용 프로그램이 아니라 운영체제)만이 그러한 "정지" 명령을 포함할 수 있다. 이 실시예의 경우 모든 운영체제에서 "정지" 명령이 삭제되고 "유휴" 루틴(예를들어 수행 쓰레드)로 바뀌는데, 이 루틴이 호출되면 "유휴" 함정 호출을 하게 된다.
몇몇 BSP 드라이버는 보조 운영체제를 위한 공유 장치를 가상화하는데 하드웨어 자원 디스패처를 보조하기 위하여 특별히 맞춰졌다. 운영체제로서는 입출력(I/O) 버스에 대한 접근을 제공하는 것처럼 보이는 "가상" 드라이버(2014) 새로 추가되어 버스로 하여금 데이터를 작성할 수 있게 한다. 실제로 가상 버스 드라이버(2014)는 메모리를 통신 매개 수단으로 사용한다. 가상 버스 드라이버는 개인 메모리(private memory 입력 데이터용) 얼마간 수출하고 다른 운영체제가 수출한 메모리(출력 데이터용)를 수입한다. 이렇게 하여 운영체제(201, 혹은 그 운영체제에서 실행되는 응용 프로그램)는 다른 운영체제로(또는 그 안에서 실행되는 응용 프로그램) 마치 서로 다른 컴퓨터 장치에서 실행되고 실제 I/O 버스로 연결된 두 운영체제 사이처럼 데이터를 넘길 수 있다.
보조 운영체제(202)는 커널 버전이 2.4.18인 리눅스로 선택하였다(단계 308). 단계 310에서 상기 보조 운영체제(202)는 다중 운영체제 환경에서 기능할 수 있도록 변경되는데, 다중 운영체제 환경은 새로운 하드웨어 설계물로 처리한다. 단계 306에서와 같이, 부팅과 초기화 순서는 변경되는데, 보조 운영체제를 하드웨어 자원 디스패처가 시작할 수 있게 하고 보조 체제가 하드웨어 자우너 디스패처 테이블에서 다른 운영체제에 할당된 것으로 명시한 하드웨어 자원들에 접근하지 못하도록 변경된다. 단계 306에서처럼 함정 호출(2022)이 추가되어 하드웨어 자원 디스패처로 제어 기능이 넘겨진다.
공유 시스템 자원용의 고유(native) 드라이버는 하드웨어 자원 디스패처에 의하여 가상화된 장치들(인터럽트 제어기, I/O 버스 브리지, 시스템 타이머, 실시간 클럭)를 다루는 새 드라이버(2028)로 교체된다. 이들 드라이버는 도 1의 컴퓨터(100)의 해당 장치에 대한 몇 가지 연산을 수행하기 위하여, 하드웨어 자원 디스패처의 가상 장치 처리기(416)를 호출한다. 하드웨어 자원 디스패처의 그러한 가상 장치 처리기(416) 각각은 핵심 운영체제의 "동료(peer)" 드라이버 루틴과 짝지어지는데, 이 루틴은 시스템 장치와 직접 상호작용하도록 마련되었다. 따라서 가상 장치 처리기에 대한 호출은 실제 장치에 대한 접근을 위해 해당 가상화 장치용의 핵심 운영체제 동료 드라이버로 연계(relay)된다. 단계 306과 같이 해당 가상 I/O 버스에 대한 읽고 쓰기용(read and write) 드라이버(2024)가 제공되어 운영체제간 통신을 할 수 있다.
보조 운영체제의 인터럽트 서비스 루틴은 해당 가상 인터럽트(하드웨어 자원 디스패처의 인터럽트 처리 루틴(412)에 발한 호출의 형태)에 대응하는 각각의 가상 인터럽트 서비스 루틴(2026)을 제공하기 위하여 변경되는데. 그에 의하여 실제 인터럽트나 이벤트에 반응하지 않게 된다. 보조 운영체제의 루틴(인터럽트 서비스 루틴 포함) 역시 하드웨어 인터럽트의 금지(masking, 적어도 핵심적인 연산을 제외한 모든 루틴에 대하여)를 해제하도록 바뀐다. 그리하여 핵심 운영체제(201)가 보 조 운영체제(202와 여타)들을 접수할 수 있게 된다. 다시 말해서, 가상 인터럽트에 대한 보조 운영체제의 응답 자체가 핵심 운영체제(201)에 대한 실제 인터럽트에 의하여 차단될 수 있다. 이에는 전형적으로 다음의 경우들이 속한다.
。금지(mask)하거나 금지 해제하는 이벤트(프로세서 수준의 인터럽트)
。금지 상태를 저장하고 복원하는 이벤트
。인터럽트 원인을 파악하는 작업(인터럽트 제어 장치)
。소스 수준(인터럽트 제어 장치)에서 인터럽트의 금지 또는 금지 해제
공유 하드웨어 장치(I/O 버스 브리지, 시스템 콘솔, 시스템 타이머와 실시간 클럭)에 접근하기 위하여 새 가상 장치 드라이버(2028)이 추가된다. 이들 드라이버는 컴퓨터(100)의 해당 장치로부터 데이터를 읽고 장치에 데이터를 써 넣기 위하여 하드웨어 자원 디스패처의 가상 장치 처리기(416)를 호출한다.
이러한 기능을 가질 수 있도록 본 실시예에서 리눅스 커널(2070)은 가상 하드웨어 자원 디스패처 구조 서브트리(I-386과 파워PC 변형물용의 nk-i386과 nk-ppc)를 추가하여 변경되는데, 이 때 소수의 변경된 파일도 추가된다. 변경되지 않은 파일은 기존 형태 그대로 재사용된다. 원래의 서브트리는 유지되지만 사용되지는 않는다.
단계 312에서 하드웨어 자원 디스패처(400)가 작성된다. 하드웨어 자원 디 스패처는 다음의 기능을 하는 루틴(도 4 참조)을 제공하는 프로그램 코드를 갖춘다.
。 자신을 부팅하고 초기화하는 기능(402)
。하드웨어 자원(포트와 같은 장치)의 리스트와 각 자원이 해당 운영체제에 유니크하게 배당된 사항을 나타내는 할당 항목(allocation entry)을 담은 테이블을 저장하는 기능(403)
。하드웨어 자원 디스패처 할당(allocation) 테이블을 완성하는 핵심 운영체제를 부팅하고 초기화하는 기능(404)
。보조 운영체제들을 부팅하고 초기화하는 기능(406)
。운영체제 사이의 교환(switching) 기능(408)
。운영체제 사이의 스케줄링 기능(410)
。인터럽트 처리(412, 실시간 운영체제 인터럽트 서비스 루틴을 사용하고 필요한 경우 보조 운영체제의 가상 인터럽트 서비스 루틴에 데이터를 공급)
。각 운영체제로부터의 함정 호출을 처리하는 기능(414)
。공유 장치들에 대한 보조 운영체제의 접근을 처리하는 기능(416)
。가상 I/O 버스상에서 운영체제간의 통신을 처리하는 기능(418)
이하 기재할 실시예들에서는 디스패처가 버그 제거 프레임워크도 제공할 수 있다.
운영체제 교환기(408, switcher)
한 운영체제에서 다른 운영체제로 교환하기 위해서 운영체제 교환기(408)는 현재 실행 중인 운영체제의 "맥락(context)"-레지스터 값과 같은 상태 변수 집합의 현재값-을 저장하고, 다른 운영체제의 저장된 맥락을 복원하며 상기 다른 운영체제가 바로 그 전 상태에서 작업 수행을 재개하는 호출을 하도록 설정된다. 프로세서가 메모리의 한 부분이나 가상 혹은 간접 주소 지정 테크닉을 사용하는 때에는 현 메모리 공간에 대한 포인터를 저장하는 데이터 구조나 레지스터에서 따라서 치환(swapping) 일어난다. 예를 들어 각 운영체제는 그러한 서로 다른 메모리 공간에서 작동하는데, 이 메모리 공간은 그 공간에 대한 포인터 값을 포함하는 맥락에 의하여 정의된다.
구체적으로 교환기는
。현재 운영체제가 유휴 상태에 들어가면 현 운영체제로부터 스케줄링 상 다음으로 예정된 운영체제로 명시적(explicit) 교환 기능(예를 들어 함정 호출)을 수행하거나,
。하드웨어 인터럽트가 일어나면 보조 운영체제로부터 핵심 운영체제로 암시적(implicit) 교환 기능을 수행한다. 교환 기능은 이하 기술하는 것처럼 함정 호출이나 실제 혹은 가상 인터럽트시에도 일어날 수 있다.
스케줄러(410)
스케줄러(410)는 한 운영체제를 마치고 나서 어느 보조 운영체제(보조 운영체제가 여럿일 때)로 교환할지를 선택함으로써 각 운영체제에 사용 가능한 프로세서 시간의 일부를 할당한다. 본 실시예에서 운영체제는 고정된 우선 순위 스케줄 링에 따라 선택된다. 시간 공유(time sharing)나 프로세서 시간 최소분률 보증 방식(guaranteed minimum percentage)에 따른 선택 기준을 제시하는 다른 실시예도 이하 검토한다. 그러나 각 경우에 핵심 운영체제는 유휴 상태에 있을 때에만 접수당한다.
다음의 실시예에서 핵심 운영체제는 스케줄러(410)에 명시적으로 보조 운영체제가 자신을 접수할 수 있는 시간을 알려서 핵심 운영체제에서 수행되고 있는 작업보다 더 높은 우선순위로 보조 운영체제가 작업 수행을 할 수 있도록 모든 보조 운영체제가 CPU에 접근하는 것을 얼마간 허용할 수 있다. 따라서 한 실시예에서 핵심 운영체제의 인터럽트 서비스 루틴은 접수당하지 않기 때문에 그 결과 핵심 운영체제가 외부 이벤트나 실시간 클럭이 제공하는 타이밍 신호에 언제나 응답할 수 있게 되어 실시간 작동을 유지하게 된다.
가상화 프로세서 예외의 처리
하드웨어 자원 디스패처는 다음과 같이 프로세서 예외(일례로 CPU 인터럽트 또는 코프로세서 인터럽트)를 처리하도록 마련되었다.
。먼저 핵심 운영체제를 통하여 프로세서 예외를 인터셉트하고,
。다음으로 하나 또는 여럿의 보조 운영체제에 그에 상응하는 가상 예외를 고지하고, 해당 보조 운영체제를 스케줄러가 다음에 호출할 때 그 데이터를 저장하며, 해당 보조 운영체제에서 대응하는 가상 인터럽트 서비스(2026)를 호출하며,
。마지막으로 보조 운영체제에서 발생한 미결 가상 예외를 모두 금지하거나 금지 해제한다.
가상화된 예외는 전형적으로 다음과 같이 두 경우에 쓰인다.
。첫째로 보조 운영체제에 하드웨어 장치 인터럽트(비동기(asynchronous) 프로세서 예외의 형식으로 배달됨)를 전달하는 경우
。둘째로 운영체제간 교차 인터럽트, 즉 한 운영체제에 의하여 상대방 인터럽트(비동기 예외의 형식으로 배달됨)용으로 생성된 인터럽트를 구현하는 경우
함정 호출 처리기(414)
다음 기재를 읽으면 함정 호출 처리기의 작동 원리가 명백해질 것이다. 처리기의 주된 목적은 한 운영체제가 정지(그리고 따라서 CPU 자원을 쓸 필요 없을 때)되었을 때 스케줄러와 교환기가 운영체제를 다른 것으로 바꿀 수 있게 하는 데 있다. 부가적인 목적인 시스템 콘솔과 같은 하드웨어 자원 디스패처를 후속 실시예들에서 논할 방식과 같이 버그 제거용으로 쓰기 위하여 호출하는 데 있다.
가상화 장치(416)
앞서 밝힌 바와 같이 각 운영체제는 각 공유 장치(예를 들어 인터럽트 제어기, 버스 브리지, 시스템 타이머, 실시간 클럭)마다 디바이스 드라이버를 제공하여 그 장치에 대한 동료 수준(peer level) 드라이버 집단을 형성한다. 실시간 운영체제는 실제로 해당 장치에 접근하는 데 쓰이는 드라이버를 제공하고, 나머지 체제는 가상 장치 드라이버를 제공한다.
하드웨어 자원 디스패처의 공유 장치 처리기(416)는 각 장치를 위하고 그 장치의 모든 동료 장치(peer device)가 접근할 수 있는 저장된 데이터 구조를 공급한다. 해당 장치에 접근할 때나 혹은 이미 접근한 때에는 그 장치 드라이버가 접근한 세부 기록을 가지고 해당 데이터 구조에 저장된 자료를 갱신한다. 동료 드라이버들은 교차 인터럽트(앞서 설명한 바대로)를 사용하여 해당 데이터 구조가 막 갱신되었다는 이벤트를 다른 동료 드라이버에 고지하는 신호를 보낸다.
인터럽트 제어 장치에 접근하는데 쓰이는 드라이버는 앞서 설명한 가상화 예외 메카니즘을 사용하여 아래와 같이 하드웨어 인터럽트를 처리한다.
。핵심 운영체제 장치 드라이버는 하드웨어 인터럽트를 처리하고 보조 운영체제의 동료 드라이버에게 가상화된 예외로서 전달한다.
。보조 운영체제는 그 가상화된 예외를 금지하거나 금지 해제하는 루틴(앞서 설명)을 사용하여 인터럽트를 허용(enable)하거나 허용하지 않는다.
I/O 버스와 그 브리지를 공유하는 것은 그에 연결된 장치들이 모두 같은 운영체제에 할당되지 않았을 필요하다. 따라서 장치를 할당할 때 가능한 한 같은 I/O 버스에 연결된 장치들은 같은 운영체제에 할당한다. 반드시 공유해야 하는 경우는 자원 할당 테이블(404)이 버스에 대한 자원(주소 공간, 인터럽트 라인, I/O 포트) 할당을 가리키는 descriptor 데이터를 저장하여 어느 운영체제가 어느 자원을 가지는지 가리켜 준다.
실시예의 구현
최종적으로 단계 314에서 하드웨어 자원 디스패처와 운영체제를 위한 프로그램 코드는 도 1의 컴퓨터(100)와 함께 제공되는 배분 가능한 이진 컴퓨터 프로그램 제품으로 변환 해석(compile)을 거친다.
본 발명의 한 측면으로서 공급할 수 있는 것은 개발 환경 제품(development environment product)으로서, 사용자로 하여금 사용할 서로 다른 운영체제들을 직접 선택할 수 있고 각 운영체제용의 응용 프로그램을 선택하고 개발할 수 있게 하며, 응용 프로그램과 운영체제를 하나의 양도 가능한 제품으로 통합하고, 운영체제를 부팅하며, 수행 가능한 응용 프로그램 2진수 코드를 개시할 수 있는 컴퓨터 프로그램이다. 이는 www.jaluna.com에서 구할 수 있는 C5 개발 환경에 기초하였고 또 그와 유사하다.
부팅과 초기화시 실시예의 작동
도 5에 따른 본 실시예의 부팅과 초기화 프로세스는 아래와 같이 이루어진다.
ROM(106)에 저장된 부트스트래핑용 프로그램(4022, trampoline)이 전원 공급되면 가장 먼저 수행되고, 이 프로그램은 다시 하드웨어 자원 디스패처 프로그램(400)의 나머지 부분을 메모리에 설치하는 프로그램(4024)를 시작하는데. 이 프로그램은 또 디스패처를 시작하여 시스템 이미지 배치를 기술하는 데이터 구조(아래 설명)를 한 인수(argument)로 넘기게 된다.
하드웨어 자원 디스패처는 시스템 콘솔로 사용될 수 있는 직렬 회선(serial line)을 초기화한다. 이어서 핵심 운영체제부터 시작하여 각 운영체제에 차례로 메모리 공간(운영체제 환경)을 할당한다. 하드웨어 자원 디스패처는 따라서 제2수준의 시스템 커널 부트 로더(second level system kernel loader)로 작용한다.
각 운영체제 커널은 이어서 자신의 초기화 단계에 접어들어 자원 할당 테이블(404)에 남아 있는 자원 중에서 자신이 독점할 자원들을 선택하고 초기 서비스와 응용 프로그램들을 시작한다.
도 6은 시스템 이미지를 형성하는 메모리 주소 할당의 사례를 도시한다. 하드웨어 자원 디스패처와 운영체제가 변형 해석(compile)될 때 메모리 내의 특정 위치가 할당한다. 도 6에 나타낸 바처럼, 메모리 내의 이들 위치의 모임이 시스템 이미지를 규정한다. 시스템 이미지는 하드웨어 자원 디스패처(602)가 위치한 제1 메모리 뱅크(602), 실시간 운영체제가 위치한 제2 메모리 뱅크(604), 보조 운영체 제가 위치한 제3 메모리 뱅크(606), 그리고 이 실시예에서는 보조 운영체제(리눅스)의 루트 파일 시스템을 담은 RAM 디스크가 위치한 제4 메모리 뱅크(608)로 구성된다.
시스템 이미지는 영구 저장장치(즉 휴대전화나 PBX와 같은 전형적인 실시간 장치를 위한 읽기 전용 메모리)에 저장된다. 남은 메모리 뱅크는 각 운영체제가 응용 프로그램을 적재하고 실행할 수 있는 환경으로서 각 운영체제에 할당된다.
운영체제 맥락을 위한 메모리 할당
부팅되는 동안, 각 운영체제는 자신의 설정에 따라 필요한 총 메모리 용량을 만족하기 위하여 그에 맞는 메모리 공간을 할당한다. 메모리 뱅크를 운영체제에 할당한 이후에는 운영체제 자체의 물리적 메모리 관리 지침(management scheme)을 통하여 관리한다. 운영체제는 모든 다른 메모리를 무시한다.
가상 메모리 할당
각 운영체제는 하드웨어 자원 디스패처나 서로를 간섭하지 못하도록 각각 별도의 가상 메모리 공간이 할당 받는다. 각 운영체제의 사용자 주소 공간(즉, 레인지(range))과 관리자(supervisor) 주소 공간(즉 레인지)은 서로 다른 메모리 관리 장치(MMU, memory management unit) 맥락 식별자(identifier, ID)을 할당받는데, 이들은 주소가 겹치는 서로 다른 가상 메모리 공간을 구별할 수 있게 하여 준다. MMU 맥락 ID는 운영체제가 변환 해석(compile)될 각 운영체제에 지정된다.(도 3의 단계 314)
이러한 해결책을 쓰면 하드웨어 자원 디스패처가 서로 다른 운영체제 사이를 교환할 때 변환 캐시(translation cache, TLB)를 디스크로 내보낼(flush) 필요가 없고 따라서 시간을 절약하게 된다. 대신 다른 운영체제 사이를 교환하는 작업은 현재 기능중인 운영체제의 MMU 맥락 ID를 저장하고, 바꿀 운영체제의 기존 MMU 맥락 ID를 기억해 내는 것으로 이루게 된다.
입/출력 장치의 할당
앞서 설명한 것처럼 할당 테이블(404)은 각 운영체제에 어떠한 장치가 유니크하게 할당되는지 가리켜 준다. 게다가 테이블(404)은 그러한 장치에 어느 입/출력 자원(직접 메모리 접근(direct memory access, DMA) 장치, 입/출력 포트, 인터럽트 등)이 할당되었는지 가리켜 주므로 이들 자원을 이해관계가 갈리지 않게 사용할 수 있게 한다. 전형적으로는 많은 장치들이 복제(duplication)되는바, 이 방식으로 발생할 수 있는 이해관계의 상충을 상당히 줄일 수 있다.
분배 방식은 운영체제 설정 지침(예를 들어 C5의 경우, 장치들은 장치 트리에 명시된다)에 바탕을 둔다. 부팅시 장치를 운영체제에 할당하고, 또 부팅의 순서대로 할당이 일어나므로 핵심 운영체제는 테이블(404)에 기재된 가용 자원에 대한 첫 번째 선택권을 가지며, 보조 운영체제들은 차례로 남은 자원들을 할당받는다. 각 운영체제가 초기화되면서 각 체제는 이 장치들을 감지하고 하드웨어 자원 디스패처의 간섭을 받지 않은 채 장치에 고유한 드라이버를 사용한다.
보조 운영체제의 핫(hot) 재부팅
현 실시예에서는 다른 운영체제를 계속 실행하면서 보조 운영체제를 재부팅(예를 들어 시스템 장애때문에)할 수 있다. 시스템 자원을 분리하였으므로 보조 운영체제의 시스템 장애(crash)는, 그 보조 운영체제의 재부팅과 마찬가지로, 핵심 운영체제(또는 다른 보조 운영체제)의 계속된 실행을 방해하지 않는다.
본 실시예에서 하드웨어 자원 디스패처에 대한 운영체제의 “중단”과 “시작” 함정 호출은 핵심 운영체제로부터 보조 운영체제를 종료하고 다시 시작하는 것을 돕는다. 덧붙여서 하드웨어 자원 디스패처는 부팅시 원래의 시스템 이미지 사본을 하드웨어 자원 디스패처에 할당된 메모리 내의 영구 메모리에 저장한다. 한 예제로서 이 실시예의 핫(hot) 재시작은 다음과 같이 관리된다.
처음 부팅할 때, 하드웨어 자원 디스패처는 해당 보조 운영체제 메모리 이미지의 사본을 저장한다. 핵심 운영체제는 보조 운영체제의 작동을 주기적으로 감시하기 위한 소프트웨어 감시 드라이버 루틴(예를 들어 보조 운영체제의 연속적인 작동을 점검하기 위하여 타임아웃을 설정하고 보조 운영체제에서 실행 중인 동료 드라이버가 유도한 이벤트를 기다리기)을 가지고 있다.
핵심 운영체제가 보조 운영체제의 작업 수행 실패나 중지를 감지하면 하드웨어 자원 디스패체에게 (그 보조 운영체제의) “중단” 그리고 그 다음에 “시작” 함정 호출을 하게 된다. 하드웨어 자원 디스패처는 그 보조 운영체제의 시스템 이미지 사본을 복원하고 메모리로부터 재부팅하여 그 보조 운영체제를 재시작한다. 실시예의 검사 결과 리눅스 보조 운영체제는 잠금(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)은 하드웨어 자원 디스패처와 하드웨어 자원 디스패처 인터페이스를 통하여 통신하는데, 인터페이스는
。운영체제 맥락(즉 운영체제를 교환하기 위하여 저장하고 복원하여야 되는 상태 변수의 모임)과 하드웨어 저장소(repository)를 나타내는 데이터 구조
。운영체제 환경에서 수행되는 함수의 모임
。하드웨어 자원 디스패처 환경에서 수행되는 함정 호출 루틴의 모임을 갖추고 있다.
운영체제 중 어느 쪽도 프로세서 시간을 요하지 않는 때(예를 들어 양쪽 모두 “유휴” 상태에 도달한 때)에는 하드웨어 자원 디스패처(400)가 핵심 운영체제의 유휴 스레드(thread)로 교환하는데, 여기서 다음 인터럽트나 이벤트를 기다리게 된다. 따라서 핵심 운영체제의 서비스 루틴은 핵심 운영체제로 먼저 교환할 필요 없이 곧바로 인터럽트를 처리할 수 있다. 이 과정에서 언젠가는 인터럽트나 이벤트가 일어난다. 예를 들어 데이터 포트에서 패킷(packet)을 수신하면 UDP/IP 스택을 수행하는 실시간 운영체제가 인터럽트를 처리할 수 있게 된다. 반대로 사용자는 키보드나 마우스를 조작하여, 인터럽트로 하여금 문서 편집기(208)와 상호작용하는 보조 운영체제(202)의 GUI를 작동하게끔 할 수 있다. 혹은 시스템 클럭이 미리 예정된 시간이 경과하여 응용 프로그램이 작업 재수행을 개시하여야 함을 알리거나 해당 운영체제가 기능을 수행하여야 한다고 가리켜 줄 수도 있다.
핵심 운영체제는 그 다음, 아래에 설명된 대로 서비스 루틴을 인터럽트에 대하여 가동한다.
인터럽트와 이벤트 처리
이미 핵심 운영체제에 진입하지 못했다면, 하드웨어 자원 디스패처 인터럽트 처리기(412)는 운영체제 교환기(408)을 호출하여 핵심 운영체제로 교환하고 그 다음 핵심 운영체제(201)의 인터럽트 처리 루틴(412)를 호출한다. 핵심 운영체제에 고유하게 설계된 장치나, 미리 예정된 특정한 값을 가지는 공유장치에서 비롯되었기 때문에 인터럽트가 핵심 운영체제에 대한 것인 경우, 핵심 운영체제 인터럽트 서비스 루틴은 그 처리에 필요한 조치를 취한다. 그렇지 않은 경우, 제어 기능은 하드웨어 자원 디스패처로 다시 넘어간다.
핵심에서 보조 운영체제로의 교환
도 7을 참조할 때, 이 실시예에서 시스템은 핵심 운영체제(201)에서 응용 프로그램(207a)의 스레드(702)를 실행하고 있다. 인터럽트가 일어나면 핵심 운영체제 인터럽트 서비스 루틴(ISR, 704)이 인터럽트를 서비스한다. 완료시에는 제어 기능이 다시 스레드(702)와 핵심 운영체제(201) 스케줄러가 수행하는 나머지 스레드 중 어느 것으로라도 넘어가게 된다. 모든 스레드의 처리가 끝나면, 핵심 운영체제는 수행을 마치고 자신의 "유휴" 스레드 스케줄링을 시작한다. 그에 따라 핵심 운영체제의 "유휴" 함정 루틴은 하드웨어 자원 디스패처(400)에 "유휴" 함정 호출을 발하게 된다. 하드웨어 자원 디스패처는 그 다음 다음의 기능의 루틴을 수행한다.
。인터럽트 처리기(412)에 현재 가상 인터럽트를 저장되어 있으면 처리기(412)는 이들을 보조 운영체제로 전달한다.
。하드웨어 자원 디스패처 운영체제 스케줄러(410)는 작업을 수행할 해당 보조 운영체제(202)를 선택한다. 운영체제 교환기(408)는 핵심 운영체제 맥락 저장부(708)에 있는 현재 맥락(전형적으로는 프로세서 MMU와 상태 레지스터, 명령과 스택 포인터들)을 저장한다. 그리고 나서 교환기는 저장된 해당 보조 운영체제의 작업 수행 맥락(708)을 찾아내어 관련 레지스터상에 기록한다.
。해당 보조 운영체제에 대한 가상 인터럽트가 있는 경우는, 인터럽트 처리기(412)가 그 보조 운영체제의 유관 인터럽트 처리 루틴(ISR, 710)을 호출하는데, 이 루틴은 인터럽트를 서비스하고, 완료시에는 그 보조 운영체제의 스레드(712) 작 업 수행의 최종 상태로 복귀한다.
인터럽트 처리기(412)가 현재 아무 미결 인터럽트를 가지지 않은 경우에, 하드웨어 자원 디스패처 운영체제 교환기(408)는 보조 운영체제로 하여금 복원된 운영체제 맥락 내에 저장된 프로그램 카운터 값(program counter value)를 사용하여 인터럽트 직전 상태, 이 경우는 해당 스레드(712)부터 작업 수행을 재개하도록 한다.
따라서 핵심 운영체제(201)가 어떤 기능을 수행한 뒤(자신의 서비스나 응용 프로그램를 서비스하거나 또는 다른 운영체제에 대한 인터럽트를 서비스한 뒤), 하드웨어 자원 디스패처는 스케줄러(410)가 정하는 데에 따라 다음 보조 운영체제(202)로 제어 기능을 넘긴다.
인터럽트시 보조에서 핵심 운영체제로의 교환
도 8을 참조할 때, 보조 운영체제에서 핵심 운영체제로의 교환 과정을 이하 개시한다. 이 경우 시스템은 핵심 운영체제(202)에서 실행되는 응용 프로그램(208a)의 스레드(712) 작업을 수행하고 있다.
하드웨어 인터럽트가 일어나면, 하드웨어 자원 디스패처는 운영체제 교환기를 작동시켜 맥락 저장부(708)에 해당 보조 운영체제 맥락을 저장한다. 디스패처는 맥락 저장부(706)로부터 상태 변수값을 복원하여 주 운영체제(201)로 교 환하고, 주운영체제(201)의 인터럽트 서비스 루틴을 호출한다. 인터럽트 서비스를 마친 뒤, 주운영체제(201)의 스케줄러는 제어 기능을 인터럽트 서비스 루틴(704)로부터 기존에 수행되고 있던 스레드(704)(혹은 수행될 스레드) 아무나로 넘기게 된다.
인터럽트 서비스 루틴과 모든 스레드를 처리한 뒤, 주운영체제(201)는 제어 기능을 하드웨어 자원 디스패처로 넘기고, 디스패처는 도 7에서 논의한 방식으로 주운영체제(201)로부터(맥락 저장부(706)에 상태 변수를 저장) 선택한 보조 운영체제(202)(맥락 저장부(708)로부터 상태 변수를 찾아냄)로 교환한다.
운영체제간 통신-가상 버스(418)
가상 버스 루틴은 각 운영체제의 가상 버스 드라이버와 협력한다. 가상 버스 루틴은 compact PCI(cPCI) 백플레인(backplane)에 플러깅(plugging)한 cPCI 보드와 유사한, 운영체제 사이를 연결하는 물리적 버스를 에뮬레이션을 수행한다. 각 운영체제는 이 가상 버스의 가상 버스 브리지 장치에 대한 드라이버 루틴을 제공받아, 운영체제와 그 응용 프로그램이 원시(raw) 데이터 전송으로부터 완전한 IP 프로토콜 스택에 이르기까지 원하는 어떠한 프로토콜과도 통신할 수 있게 하여 준다.
하드웨어 자원 디스패처 가상 버스는 위에서 이미 설명한 공유 메모리와 시스템 교차 인터럽트 원리에 그 바탕을 둔다. 자세히는 가상 버스 루틴(418)이 C5 buscom DDI:syscom을 에뮬레이션 수행하는데, 이는 가상 버스 브리지를 공유하는 장치를 규정하여 가상 버스를 통한 메모리 수출(공유)과 다른 운영체제를 향하는 교차 인터럽트의 발생을 가능하게 한다.
각 보조 운영체제의 각 가상 버스 드라이버는 스타트업 타임(startup time)이 되면 하드웨어 자원 디스패처 하드웨어 저장소에 그러한 가상 버스 브리지를 만든다. 이렇게 함으로써 드라이버는 자신의 개인 메모리의 한 영역을 수출(공유)하고, 자신의 호스트 시스템 내에서 인터럽트를 제기하는 수단을 제공한다.
따라서 제1운영체제의 가상 버스 드라이버는 보조 운영체제로 데이터를
Figure 112005057207976-PCT00001
。보조 운영체제의 동료 가상 드라이버가 수출하는 메모리에 기록하고 그 다음,
。그 보조 운영체제의 동료 버스 드라이버에게 데이터 사용이 가능하다고 알리는 교차 인터럽트를 일으켜서 데이터를 전송한다.
반대 방향(들어오는 방향)으로는 가상 버스 드라이버에 그러한 데이터가 자신의 고유한 수출 메모리 영역에 저장되었다는 교차 인터럽트를 수신되면, 가상 버스 드라이브는 들어오는 데이터 업스트림(upstream, 그 대상 응용 프로그램이나 루틴이 사용할)을 전파한다.
도 9a를 참조할 때, 같은 운영체제(202)에서 실행 중인 다른 응용 프로그램(208b)와 통신할 응용 프로그램(208a)는 그 운영체제를 통하여 통신이 가능하다. 한 운영체제(201)에서 실행 중인 응용 프로그램(207b)이 다른 운영체제(202)에서 실행 중인 다른 응용 프로그램(208b)와 통신할 경우는 자신의 운영체제의 API를 사용하여 그 가상 버스에 데이터를 기록하여 통신할 수 있는데, 그 운영체제는 가상 버스 드라이버 루틴을 사용하여 데이터를 다른 운영체제(202)로 넘기며, 그 다른 운영체제(202)는 응용 프로그램(208b)에 대한 자신의 가상 버스 드라이버로부터 데이터를 전파한다.
도 9b를 참조할 때, 이 배치를 제1운영체제와 제2운영체제가 각각 다른 컴퓨터(101,102)에서 실행 중인 환경으로 옮기는 데 필요한 변경은 조금뿐이다. 다만 운영체제들이 가상 버스 드라이버 대신 실제 버스(103)용 드라이버를 사용하도록 운영체제가 사용하는 드라이버를 바꿔 주어야 할 뿐이다. 그러므로 시스템은 자신이 작동하는 하드웨어와 더욱 무관하게 된다.
하드웨어 자원 디스패처 가상 버스 사이의 통신은 응용 프로그램도 이용 가능하지만, 운영체제 커널이 여러 개의 운영체제에 배분되는 서비스를 구현하는 것을 서로 도울 수 있도록 운영체제 커널 사이에도 이용 가능하다. 이러한 "스마트"형 배분 서비스에는 운영체제 핫 재사작(앞서 설명)에 쓰이는 소프트웨어 감시와 배분되는 네트워크 프로토콜 스택이 속한다.
유럽 특허 1054332는 공통 통신 메모리에 대한 접근을 동기화하기 위하여 세마포어 록(semaphore lock)을 사용한다. 그렇나 록은 실시간과 범용 운영체제 사이에 의존도를 하나 추가한다. 본 실시예에서 록을 쓰지 않는 통신 프로토콜을 사용함으로써 이러한 단점은 피할 수 있다.
버그 제거
모범 실시예에서 하드웨어 자원 디스패처는 버그 제거 장치로서 작용하는 제2의 작동 모드가 있다. 본 실시예 제2모드에서 하드웨어 자원 디스패처는 직렬 통신선을 통하여 다른 컴퓨터("호스트" 머신)에서 실행 중인 버그 제거 소프트웨어와 통신할 수 있다. 이러한 버그 제거 프로그램은 높은 수준의 그래픽 사용자 인터페이스(GUI)를 제공하여 하드웨어 자원 디스패처를 원격 조정한다. 하드웨어 자원 디스패처의 가상화 예외 메카니즘은 규정된 예외를 인터셉트하기 위하여 사용된다. 사용자는 그 다음 하드웨어 자원 디스패처가 프로세서 예외시 어떻게 거동하는지를 설정하고 제어할 수 있으며 코드 에러, 여타 시스템 에러 또는 문제들을 진단할 수 있도록 머신과 시스템 상태 변수를 표시하게 할 수 있다.
사용자는 그러한 프로세서 예외 하나 또는 여러 개를 운영체제가 하드웨어 자원 디스패처를 함정 호출하는 바탕으로 선택할 수 있다. 선택된 예외에 기초하여 작업 수행 도중 예외가 일어나면 운영체제는 중단되고 하드웨어 자원 디스패처 에 대한 함정 호출을 수행하는데, 디스패처는 다시 현 맥락을 저장하고 호스트 머신의 버그 제어 프로그램과 상호작용할 수 있게끔 작용한다. 사용자는 이제 상태 변수들의 현재 상태(스택 포인터, 프로그램과 주소 카운터 등) 및/또는 선택한 메모리 블록의 내용을 표시하게 할 수 있다. 사용자는 어떤 특정 유형의 예외들이 버그 제거 대상인 특정 운영체제에 트랩(trap)되거나, 발생하는 즉시 아무 운영체제에라도 트랩되도록 할지를 명시할 수 있다. 이에 대응하여 함정 호출은 모든 운영체제나 아니면 단 한 운영체제에만 구현된다. 사용자는 어느 특정 유형의 예외를 작업 수행이 재개될 때 운영체제에 정상적으로 전달할지 무시할지를 명시할 수도 있다.
하드웨어 자원 디스패처는 자신의 고유한 환경에서 작동하므로 운영체제의 버그를 제거하는 데에 있어서 그 운영체제가 직접 하는 경우보다 훨씬 더 많이 제거할 수 있다. 버그 제거 장치 역할을 하는 하드웨어 자원 디스패처와 버그 제거 대상인 운영체제 사이에는 어떠한 코드도 공유하지 않는다는 점이 중요하다. 이 때문에 예를 들어 예외 벡터 또는 인터럽트 서비스 루틴과 같은 커널 저수준(low level) 코드까지 버그 제거가 가능하다.
본 실시예에 따른 전체(호스트/타겟) 버그 제거 구조(architecture)의 다른 측면들은 Chorus와 C5의 버그 제거 시스템의 경우와 비슷하며, 이들에 대해서는 http://www.jaluna.com/doc/c5/html/DebugGuide/book1.html에서 얻을 수 있는 Jaluna社 발간 "C5 1.0 Debugging Guide"에 그 기재가 있다.
보안 구조(secure architecture)
위에 설명한 본 발명의 실시예가 보안 구조를 위한 견고한 바탕이 된다는 것는 분명할 것이다. 이것은 사용자가 비보안성 응용 프로그램을 실행하는 것이 전형적인 보조 운영체제는 명시된 시스템 자원으로부터 절연되어 있고, 그 자원에 대한 접근은 오로지 하드웨어 자원 디스패처(와 주운영체제의 드라이버)를 통하여서만 이루어지기 때문이다. 따라서 주운영체제에서 다음 예와 같은 보안성 응용 프로그램을 실행할 수 있다. 암호화/암호 해제, 암호 처리된 파일에 대한 접근 허가, 패스워드와 다른 접근 정보의 관리·저장·공급, 저작권 관련 자료의 접근과 재생에 대한 관리·장부 작성 등. 보조 운영체제에서 실행 중인 응용 프로그램은 그 운영체제에 할당되지 않은 시스템 자원에 접근할 수 없으며, 또 운영체제들이 서로 다른 메모리 맥락(즉 서로 다른 공간에 대한 서로 다른 주소 지정 포인터)에서 실행 중인 때에는 보조 운영체제에서 실행 중인 응용 프로그램이 주운영체제에서 작동 중인 다른 응용 프로그램을 방해하여 그 작동의 보안성을 취약하게 하는 일은 할 수 없다.
다른 측면들과 실시예들
전술한 실시예는 다만 사례일 뿐이고 많은 다른 실시예가 가능하다는 것은 명세서 서두에서부터 분명할 것이다. 앞서 언급한 운영체제, 플랫폼고 프로 그래밍 기법은 자유로이 변경될 수 있다. 당업자에게 자명한 모든 다른 변경, 치환이나 변형물은 다음의 청구항에 기재되었는지 여부에 무관하게 본 발명의 범위에 속한다고 판단하여야 한다. 의심스러운 경우를 방지하게 위하여, 본 명세서에 기재된 모든 신규한 내용과 그 조합에 대한 권리의 보호를 구하는 바이다.
본 발명은 복수의 운영체제를 한 컴퓨터 내에서 운용하는 데에 있어서 시스템 자원을 절약하고, 통상적으로 시판되는 운영체제 프로그램에 제한적인 변화를 가하는 것만으로도 설치 가능하고 운영체제의 새 버전을 다중 운영체제 방식에서 작동하게끔 고치는 수고가 거의 들지 않는 컴퓨터의 다중 운영체제 운용 방식을 제공한다.

Claims (36)

  1. 복수의 다른 운영체제 프로그램이 동시에 같은 컴퓨터에서 수행될 수 있도록 하는 방법으로서
    상대적으로 높은 우선 순위를 가지는 제1운영체제를 선택하는 단계,
    상대적으로 낮은 우선 순위를 가지는 제2운영체제를 적어도 하나 이상 선택하는 단계,
    미리 예정된 조건 하에서 상기 운영체제들 사이를 교환하도록 정해진 공통 프로그램을 제공하는 단계,
    상기 제1운영체제와 제2운영체제가 상기 공통 프로그램에 의하여 제어될 수 있도록 조절하는 단계로 구성되는 운영체제 운용 방법.
  2. 제1항의 운용 방법에 있어서, 상기 제1운영체제는 실시간 운영체제인 운용 방법.
  3. 제1항의 운용 방법에 있어서, 상기 제2운영체제는 비실시간 범용 운영체제인 운용 방법.
  4. 제1항의 운용 방법에 있어서, 상기 제2운영체제는 리눅스 또는 그 변형물인 운용 방법.
  5. 제1항의 운용 방법에 있어서, 상기 공통 프로그램은 상기 운영체제 사이를 교환하는데 필요한 처리장치의 상태를 저장하고 그 저장된 버전으로부터 복원하도록 정해진 운용 방법.
  6. 제1항에 있어서, 상기 제2운영체제의 프로세서 예외 상황은 상기 공통 프로그램이 가상 방식으로 처리하는 운용 방법.
  7. 제1항에 있어서, 상기 공통 프로그램은 몇 가지의 프로세서 예외를 인터셉트하고 또한 그 예외 서비스를 제공하기 위하여 상기 제1운영체제의 예외 처리 루틴을 호출하도록 정하여진 운용 방법.
  8. 제1항에 있어서, 상기 제2운영체제의 프로세서 예외는 가상 예외로 고지되는 운용 방법.
  9. 제8항에 있어서, 상기 공통 프로그램은 미결(未決 pending)인 상기 가상 예외에 대응하는, 제2운영체제의 예외 처리 루틴을 호출하도록 정하여진 운용 방법.
  10. 제1항에 있어서, 상기 운영체제들 각각이 독점적으로 작동할 수 있는 독립된 메모리 공간을 각각 제공하는 단계가 추가되는 운용 방법.
  11. 제1항에 있어서, 상기 운영체제들 각각이 상기 컴퓨터에서 독점적으로 접근(access)할 수 있는 제1입력장치 또는 제1입출력장치를 각각 제공하는 단계가 추가되는 운용 방법.
  12. 제11항에 있어서, 상기 운영체제들 각각이 상기 제1입력장치 또는 제1입출력장치를 접근할 때 원시 루틴(native routine)를 실질적 변화 없이 사용하는 운용 방법.
  13. 제1항에 있어서, 상기 운영체제 각각이 접근을 공유하는 제2입력장치 또는 제2입출력장치를 제공하는 단계가 추가되는 운용 방법.
  14. 제13항에 있어서, 모든 운영체제는 제1운영체제의 상기 루틴을 사용하여 상기 제2입력장치 또는 제2입출력장치를 접근하는 운용 방법.
  15. 제1항에 있어서, 상기 제2운영체제를 상기 제1운영체제나 공통 프로그램의 인터럽트 없이 재시작하기 위한 재시작 루틴을 제공하는 단계가 추가되는 운용 방법.
  16. 제15항에 있어서, 상기 공통 프로그램은 상기 제2운영체제의 작동을 제어하기 위한 트랩 호출 메카니즘과 제2운영체제의 상태 변화를 제1운영체제에 고지하기 위한 이벤트 메카니즘 중 어느 하나 이상을 제공하는 운용 방법.
  17. 제15항에 있어서, 상기 공통 프로그램은 상기 제2운영체제 커널(kernel)의 시스템 이미지의 사본을 저장하고 그러한 사본으로부터 상기 제2운영체제 커널을 복원하도록 마련된 운용 방법.
  18. 제15항에 있어서,상기 제1운영체제는 제2운영체제가 계속하여 작동하는지를 감시할 수 있고, 제2운영체제의 시스템 장애(crash)를 감지할 수 있도록 제2운영체제와 서로 협력하는 루틴을 가지는 운용 방법.
  19. 제1항에 있어서, 상기 공통 프로그램은 상기 운영체제들의 작동 중 미리 예정된 조건이 성취된 경우 컴퓨터 장치(machine)의 상태 변수를 출력하도록 마련된 버그 제거 루틴을 제공하는 단계가 추가된 운용 방법.
  20. 제1항에 있어서, 상기 운영체제들과 공통 프로그램은 하나의 프로그램 코드로 통합된 구성으로 갖춘 운용 방법.
  21. 제1항에 있어서, 상기 운영체제들과 공통 프로그램은 컴퓨터 장치의 영구 메모리상에 내장(embedding)되는 구성이 추가된 운용 방법.
  22. 제1항에 있어서, 상기 공통 프로그램은 상기 제1운영체제와 제2운영체제 사이의 통신이나 그 운영체제에서 수행되는 응용 프로그램(application)들 사이의 통신 중 적어도 하나 이상이 가능하도록 하는 운영체제간 통신 메카니즘을 제공하도록 마련된 운용 방법.
  23. 제22항에 있어서, 상기 공통 프로그램은 통신 버스 브리지에 일치하는 가상 입력장치 또는 가상 입출력장치 중 적어도 하나를 규정하고 있어서, 상기 운영체제들이 마치 통신 버스에 의한 방식과 유사하게 통신할 수 있게끔 하는 운용 방법.
  24. 제23항에 있어서, 상기 운영체제들을 조절하는 단계는 상기 가상 버스 장치들을 관리하는 드라이버 루틴을 추가하는 것으로 구성되는 운용방법.
  25. 제1항의 단계들을 수행하기 위한 프로그램 코드로 이루어진 소프트웨어 개발 키트 컴퓨터 프로그램.
  26. 제20항에 의하여 상기 공통 프로그램과 운영체제를 통합한 컴퓨터 프로그램.
  27. 제24항의 방식에 따라 영구 메모리에 내장된 프로그램을 갖추고 중앙처리장치(CPU), 메모리 장치와 입출력 장치로 구성된 내장 컴퓨터 시스템.
  28. 중앙처리장치, 메모리 장치와 입출력장치로 구성된 컴퓨터 시스템으로서,
    상대적으로 높은 우선 순위를 가지는 제1운영체제,
    상대적으로 낮은 우선 순위를 가지는 제2운영체제,
    미리 예정된 조건 하에서 상기 운영체제 사이를 교환함으로써 상기 운영체제들을 동시에 작동하도록 마련된 공통 프로그램으로 이루어진 컴퓨터 프로그램 코드가 수행되는 컴퓨터 시스템.
  29. 제28항의 컴퓨터 시스템에 있어서, 청구항 1 내지 24의 운용 방법 중 어느 것에 의하더라도 상기 제1운영체제와 제2운영체제를 동시에 작동하도록 마련된 컴퓨터 시스템.
  30. 제1항에 있어서, 상기 운영체제 각각에 상기 공통 프로그램으로 제어권을 넘기는 유휴(遊休 idle) 루틴을 제공하는 운용 방법.
  31. 제30항에 있어서, 상기 유휴 루틴은 프로세서 정지 명령을 대체하는 운용 방법.
  32. 제1항에 있어서, 운영체제 작동 도중 프로세서 예외가 발생하였을 때, 상기 공통 프로그램은
    (ㄱ) 그 예외 서비스를 제공하기 위하여 제1운영체제의 예외 처리 루틴을 호출하고,
    (ㄴ) 상기 예외가 미리 예정된 제2운영체제에 대하여 의도된 것이라면, 가상 예외를 만들며,
    (ㄷ) 상기 예외에 대한 제1운영체제 서비스가 끝난 후에는 상기 공통프로그램이 상기 작동 중이던 운영체제를 작동하는 역할로 복귀하고
    (ㄹ) 상기 공통 프로그램이 다음에 미리 예정된 제2운영체제로 교환할 때, 미결 상태인 상기 가상 예외를 상기 예정된 제2운영체제에 고지하도록 마련되는 특징을 가지고,
    상기 가상 예외에 일치하는 상기 예정된 제2운영체제의 예외 처리 루틴이 예외 서비스를 제공하기 위하여 호출되는 운용 방법.
  33. 제1항에 있어서, 상기 제2운영체제는 인터럽트를 금지(masking)하지 못하도록 변경된 운용 방법.
  34. 제1항에 있어서, 모든 하드웨어 인터럽트는 상기 제1운영체제가 우선적으로 처리하며, 제2운영체제들에 대한 인터럽트는 가상화되고 상기 공통 프로그램이 해당 제2운영체제에 할당될 때까지 보류된 뒤, 해당 제2운영체제가 인터럽트 서비스를 제공하는 운용 방법.
  35. 제8항에 있어서, 상기 공통 프로그램은 각 보조운영체제에서 가상 예외를 금지(masking)함으로써 상기 각 운영체제가 하드웨어 인터럽트 금지 코드(masking code)를 대체하는 수단을 제공하는 결과, 주 운영체제가 상기 보조운영체제를 완전하게 접수(pre-emptable)할 수 있게 되는 운용 방법.
  36. 제9항에 있어서, 상기 두번째 가상 예외는 금지되지 않는 운용 방법.
KR1020057019290A 2003-04-09 2004-04-07 운영체제 KR20060023956A (ko)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
EP03290894A EP1467282B1 (en) 2003-04-09 2003-04-09 Operating systems
EP03290894.9 2003-04-09
US10/665,352 2003-09-22
US10/665,352 US7434224B2 (en) 2003-04-09 2003-09-22 Plural operating systems having interrupts for all operating systems processed by the highest priority operating system

Publications (1)

Publication Number Publication Date
KR20060023956A true KR20060023956A (ko) 2006-03-15

Family

ID=33161021

Family Applications (1)

Application Number Title Priority Date Filing Date
KR1020057019290A KR20060023956A (ko) 2003-04-09 2004-04-07 운영체제

Country Status (5)

Country Link
EP (1) EP1616257B1 (ko)
JP (1) JP2006522971A (ko)
KR (1) KR20060023956A (ko)
CA (1) CA2521748A1 (ko)
WO (1) WO2004090719A2 (ko)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101029498B1 (ko) * 2010-11-01 2011-04-18 엘아이지넥스원 주식회사 항공 임무컴퓨터의 부팅 방법
KR20160097892A (ko) * 2015-02-10 2016-08-18 한국전자통신연구원 가상화 기반의 보안 서비스 제공 장치 및 제공 방법
KR20170055180A (ko) * 2015-11-11 2017-05-19 삼성전자주식회사 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100383744C (zh) * 2004-12-24 2008-04-23 联想(北京)有限公司 一种计算机多操作系统的切换方法
GB0516426D0 (en) * 2005-08-10 2005-09-14 Symbian Software Ltd A method of operating a computing device through the use of extensible thread states
JP4597032B2 (ja) * 2005-10-24 2010-12-15 株式会社ソニー・コンピュータエンタテインメント コンピュータシステム、それにおける基本プログラムの起動方法、及びローダプログラム
US8082431B2 (en) * 2006-09-29 2011-12-20 Intel Corporation System and method for increasing platform boot efficiency
WO2009095812A1 (en) * 2008-01-28 2009-08-06 Nxp B.V. Dual operating systems on a single processor

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3831048A1 (de) 1988-09-12 1990-03-15 Nixdorf Computer Ag Betriebsprogramm fuer eine datenverarbeitungsanlage
US5995745A (en) 1996-12-23 1999-11-30 Yodaiken; Victor J. Adding real-time support to general purpose 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
JP3546678B2 (ja) * 1997-09-12 2004-07-28 株式会社日立製作所 マルチos構成方法
FI108478B (fi) * 1998-01-21 2002-01-31 Nokia Corp Sulautettu jõrjestelmõ
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 株式会社日立製作所 計算機システム
EP1162536A1 (en) 2000-06-09 2001-12-12 Hitachi, Ltd. Multiple operating system control method
JP2003036174A (ja) * 2001-07-25 2003-02-07 Hitachi Ltd 車載端末装置

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101029498B1 (ko) * 2010-11-01 2011-04-18 엘아이지넥스원 주식회사 항공 임무컴퓨터의 부팅 방법
KR20160097892A (ko) * 2015-02-10 2016-08-18 한국전자통신연구원 가상화 기반의 보안 서비스 제공 장치 및 제공 방법
KR20170055180A (ko) * 2015-11-11 2017-05-19 삼성전자주식회사 멀티 운영시스템을 지닌 전자장치 및 이의 동적 메모리 관리 방법

Also Published As

Publication number Publication date
WO2004090719A3 (en) 2005-10-20
CA2521748A1 (en) 2004-10-21
JP2006522971A (ja) 2006-10-05
EP1616257A2 (en) 2006-01-18
WO2004090719A2 (en) 2004-10-21
EP1616257B1 (en) 2018-08-22

Similar Documents

Publication Publication Date Title
EP2296089B1 (en) Operating systems
US7434224B2 (en) Plural operating systems having interrupts for all operating systems processed by the highest priority operating system
US8024742B2 (en) Common program for switching between operation systems is executed in context of the high priority operating system when invoked by the high priority OS
US8612992B2 (en) Operating systems
US6711605B2 (en) Multi OS configuration method and computer system
RU2398267C2 (ru) Иерархическая виртуализация посредством многоуровневого механизма виртуализации
JP2006252565A (ja) 仮想マシン環境におけるマルチレベルインターセプト処理のためのシステムおよび方法
KR20070003765A (ko) 운영체제
US20050246708A1 (en) Method of assigning virtual process identifier to process within process domain
KR20060023956A (ko) 운영체제
EP1673697B1 (en) Operating systems
Tan et al. How Low Can You Go? Practical cold-start performance limits in FaaS
EP1673693B1 (en) Operating systems
Ludwig et al. Porting openBSD to fiasco
Early ESPRIT LTR 21917 (Pegasus II) Deliverable 2.1. 2 Pentium Port Report
Root Virtualising Darwin on L4

Legal Events

Date Code Title Description
WITN Withdrawal due to no request for examination