KR20070083569A

KR20070083569A - 운영체제

Info

Publication number: KR20070083569A
Application number: KR1020077006231A
Authority: KR
Inventors: 질레스 메인; 구에나디 마슬로프
Original assignee: 쟈루나 에스에이
Priority date: 2004-08-18
Filing date: 2005-08-18
Publication date: 2007-08-24
Also published as: WO2006018307A2; CA2577493A1; EP2296089A2; WO2006018307A3; US20080155542A1; EP2296089B1; JP2008510238A; EP2296089A3; EP1805609A2; US9619279B2; CN101052949A

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)을 비실시간 운영체제(윈도우즈와 같은)의 인터럽트 관리 환경에 제공함으로써 실시간 환경을 비실시간 운영체제에 도입하려는 시도를 하였다.

널리 사용된 한 가지 방식은 "에뮬레이션"이다. 전형적인 에뮬레이션 프로그램은 실시간 운영체제에서 실행되도록 작성되고, 범용 운영체제에서 작동하도록 짜여진 다른 프로그램의 각 명령을 해석한 뒤 그에 대응하는 명령들을 실시간 운영체제하에서 수행한다. 그러나 한 명령이 언제나 다수의 명령으로 대체되기 때문에 에뮬레이션은 컴퓨터에 큰 부담을 주고, 수행 속도를 떨어뜨린다. 가상 머신(예를 들어 Java^TM 가상 머신)을 제공하는 방식에서도 비슷한 문제가 일어난다. 가상 머신을 장착한 예로서 유럽 특허 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" 완전한 이해할 만큼 충분하게 설명되지 않았음)가 실시간과 범용 운영체제를 실행하는 시스템을 기술한다. 하드웨어 인터럽트는 공통 인터럽트 핸들러(handler)가 처리하고, 몇몇 실시예에서는 실시간 운영체제가 담당하는데 실시간 운영체제는 이어서 보조(secondary) 운영체제 루틴이 관리할 소프트웨어 인터럽트를 우선 순위를 낮게 부여하여 발생시킨다.

본 발명의 목적은 복수의 운영체제를 다른 용도로 설계된 경우에까지도 동시에 실행하기 위한 개선된 시스템, 방법 및 컴퓨터 프로그램을 제공하는 데에 있다. 특히 본 발명은 운영체제 중 하나(예를 들어 실시간 운영체제)가 방해받지 않고 작업을 수행하고 다른 하나(예를 들어 범용 운영체제)는 컴퓨터의 나머지 자원을 최대한 잘 활용하며 작업을 수행하도록 하는 것을 꾀한다. 특히, 본 발명은 ARM 프로세서를 사용한 것과 같은 RISC(Reduced Instruction Set Computer)에 의해 유용한 그러한 시스템을 제공하기 위한 것이다.

따라서, 본 발명의 측면은 청구범위 내에 정의될 것이다. 본 상세한 설명은 이전에 제출된 유럽 특허, 즉, 2003년 4월 7일에 EPO에 제출된 EP03290894.9, 2004년 4월 7일에 EPO에 제출된 PCT/EP04/003731, 및 2003년 10월 1일에 제출된 EP03292428.4를 참조하여 편입시킨다.

ARM 프로세서에 바탕을 둔 다수의 구조를 위한 하나의 특정한 이슈는 캐시 메모리 장치(cache memory unit)가 가상 주소 지정 모드(virtual addressing mode)를 사용한다는 것이다. 다중 운영체제가 작동될 때, 그만의 각 메모리 공간에서, 각각은 물리적 메모리 주소에 대한 가상 메모리의 상이한 맵핑을 사용한다. 이는 결과적으로 다른 운영체로의 교환 이후 캐쉬로부터 검색된 잘못된 데이터를 발생시킨다. 이를 해결하는 한가지 방법은 각 운영체제 교환 상에 상기 캐시 메모리의 내용을 플러쉬하는 것이다. 그러나, 이는, 첫째로, 교환 중에 지연을 증가시키기 때문에, 그리고 둘째로, 캐시를 플러쉬한 이후 최초의 메모리 접근을 저하시키기 때문에 실시간 응용 프로그램에 바람직하지 않다. 따라서, 본 발명의 일 측면에서, 우리는 강제로 운영체제들 모두가 동일한 커널 마상 맵핑을 사용하도록 한다.

다른 이슈는 ARM 프로세서가 다수의 추가적 실행 모드(5 또는 6, 배부분의 프로세서들에서 발견할 수 있는 보통의 "사용자(user)" 및 "관리자(supervisor)" 모드와는 대조적)를 가진다는 것이다. 그러므로 운영체제 사이의 변화는 실행 모드 사이에 변화를 추가적으로 포함할 수 있다. 이를 허용하기 위해 운영체제 사이의 각 교환 상에 모든 레지스터의 상태를 저장(즉, 스택으로)하는 것을 포함할 것이다. 이는 상기 교환을 늦출 것이다. 따라서, 본 발명의 일 측면에서, 우리는 운영체제 전부가 "스크래치" 모드에 관계된 레지스터(예컨대, 레지스터 13 내지 15)를 사용하도록 요구하며, 그에 따라, 그들이 어떻게 발견되고 남겨지는지 신경쓰지 않는다. 여하튼 많은 경우 그와 같이 행함을 우리는 관찰할 수 있고; 다른 경우, 상기 운영체제의 일부를 다시쓸 필요가 있을 수 있다. 그 다음, 운영체제는 "사용자" 모드로 교환되고, 그에 따라 전부는 사용자 모드에서만 일어나는 나노커널로 (그리고 따라서 다른 운영체제로) 전송된다. 그러므로, 한 운영체제가 다른 운영체제로 교환될 때 (예컨대, 그가 완료된 작동을 가질 때 유휴 작업에 의해) 이들 레지스터 상태를 저장할 필요는 없다.

본 발명의 일 측면에서는 더 상위 모드에 있을 때, 운영체제는 미리 비워질 수는 없다(pre-emted) - 운영체제는 일반적으로 단지 코드의 매우 짧은 세그먼트(segment)만을 위해 상기 모드를 사용함을 발견했다.

서론

시스템 하드웨어

본 운영체제를 적용할 수 있는 컴퓨터(100)는 ARM Ltd (www.arm.com)에서 이용 가능한 SRM 프로세서와 http://www.arm.com/documentation/ARMProcessor_Cores/index.html 에 있는 기술 매뉴얼 및 데이터 시트에 설명된 것과 같은 중앙 처리 장치(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는 본 발명에 따라 서로 다른 컴퓨터상의 서로 다른 운영체제에서 실행되는 응용 프로그램 사이의 통신을 도시하며;

도10은 운영체제에 의해 사용된 메모리 맵핑을 도시하며;

도11은 나노커널 및 운영체제 사이의 인터페이스를 도시한다.

상기 첨부된 도면을 참조하면서 본 발명의 실시예들을 기술하기로 한다. 이는 어디까지나 예시일 뿐이다.

모범 실시예의 원리 요약

모범 실시예에서 도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 인터럽트 또는 코프로세서 인터럽트)를 처리하기 위해 예외 메커니즘을 제공하도록 마련되었다.

。먼저 핵심 운영체제를 통하여 프로세서 예외를 인터셉트하고,

。다음으로 하나 또는 여럿의 보조 운영체제에 그에 상응하는 가상 예외를 포스트(post)하고, 해당 보조 운영체제를 스케줄러가 다음에 호출할 때 그 데이터를 저장하며, 해당 보조 운영체제에서 대응하는 가상 인터럽트 서비스(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운영체제의 가상 버스 드라이버는 보조 운영체제로 데이터를

。보조 운영체제의 동료 가상 드라이버가 수출하는 메모리에 기록하고 그 다음,

。그 보조 운영체제의 동료 버스 드라이버에게 데이터 사용이 가능하다고 알리는 교차 인터럽트를 일으켜서 데이터를 전송한다.

반대 방향(들어오는 방향)으로는 가상 버스 드라이버에 그러한 데이터가 자신의 고유한 수출 메모리 영역에 저장되었다는 교차 인터럽트를 수신되면, 가상 버 스 드라이브는 들어오는 데이터 업스트림(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)

위에 설명한 본 발명의 실시예가 보안 구조를 위한 견고한 바탕이 된다는 것는 분명할 것이다. 이것은 사용자가 비보안성 응용 프로그램을 실행하는 것이 전형적인 보조 운영체제는 명시된 시스템 자원으로부터 절연되어 있고, 그 자원에 대한 접근은 오로지 하드웨어 자원 디스패처(와 주 운영체제의 드라이버)를 통하여서만 이루어지기 때문이다. 따라서 주 운영체제에서 다음 예와 같은 보안성 응용 프로그램을 실행할 수 있다. 암호화/암호 해제, 암호 처리된 파일에 대한 접근 허가, 패스워드와 다른 접근 정보의 관리·저장·공급, 저작권 관련 자료의 접근과 재생에 대한 관리·장부 작성 등. 보조 운영체제에서 실행 중인 응용 프로그램은 그 운영체제에 할당되지 않은 시스템 자원에 접근할 수 없으며, 또 운영체제들이 서로 다른 메모리 문맥(즉, 서로 다른 공간에 대한 서로 다른 주소 지정 포인터)에서 실행 중인 때에는 보조 운영체제에서 실행 중인 응용 프로그램이 주 운영체제에서 작동 중인 다른 응용 프로그램을 방해하여 그 작동의 보안성을 취약하게 하는 일은 할 수 없다.

이제 하기에 특히 바람직한 실시예를 설명할 것이다.

바람직한 실시예

1 서론

본 명세서는 ARM 구조에 기반을 둔 Jaluna 나노커널 환경을 설명한다. 상기 Jaluna 나노커널 디자인의 일반적인 원리는 이미 이전 명세서 Jaluna -2: A Multi - System Programming Environment (JL/TR-02-80.0.3)에 설명되어 있다. 본 명세서는 오히려, 특히, 상기 나노커널 환경의 초석인 나노커널 실행부 상에서 나노커널 구현의 특정한 측면인 ARM에 초점을 맞춘다.

본 명세서는 운영체제를 넘어서 MMU와 마찬가지로 CPU를 동시에 분배하는 다중 독립 운영체제를 실행시킬 수 있는 나노커널 실행부를 실행하기 위하여 상기 ARM 프로세서를 사용하는 방법을 설명한다.

본 명세서는 또한 상기 나노커널 실행부가 하드웨어 인터럽트를 관리하는 방법을 설명한다. 특히, 주 운영체제에 대해 하드웨어 인터럽트를 인터셉트하고 전달하는데 사용된 메커니즘 및 보조 운영체제로 제공된 메커니즘을 인터럽트하는 소프트웨어를 설명한다.

본 명세서는 나노커널이 단일 프로세서 컴퓨터에서 실행된다고 가정하며 따라서 SMP 구조와 관련된 측면은 여기에서 다루지 있지 않음을 주지해야 한다.

2 개요

2.1 가상 주소 공간

만약 상기 MMU가 상기 ARM 구조의 특정 실행 상에 존재한다면 운영체제 전부와 상기 나노커널은 항상 가상 주소 공간 내에서 구현시켰으며, 즉, 상기 MMU를 항상 허용시켰다. 상기 나노커널 코드가 메모리 문맥 안에서 시간에 따라 많은 변화 하에 실행됨에 주의하라. 반면에, 상기 MMU는 나노커널이 필요로 하지 않으며, MMU 없이 ARM 프로세서를 가정한다. 이 경우, 운영체제 전부와 상기 나노커널을 물리적 주소 공간 내에서 실행시켰다.

본 설명에서, 용어 메모리 루트 디렉토리가 문맥은 시스템 제어 보조 프로세서(CP 15) 내에서 변환 테이블 베이스 레지스터에 의해 명시된 하드웨어 주소 변환 트리를 나타낸다.

일반적으로, 사용자 모드 보호를 지지하는 운영체제는 개인 사용자 가상 주소 공간을 관리할 수 있도록 다중 메모리 문맥(사용자 프로세스당 하나)을 생성한다. 상기 커널은 각각의 시간에 한 사용자 프로세스에서 다른 사용자 프로세스로 교환시키는 상기 메모리 문맥을 변경시킨다. 한편, 상기 사용자 주소 공간과 함께 상기 운영체제 커널은 또한 모든 메모리 문맥 내에서 복제되는 유일한 관리자 주소 공간을 관리한다. 사용자 및 관리자 가상 주소는 ARM 구조 상에서 절대 겹치지 않 는다.

만약 MMU가 존재하지 않는다면, 운영체제는 모든 프로세서들 사이에서 동일한 주소 공간을 공유하고, 따라서 메모리 문맥 교환을 필요로하지 않는다. 이 경우, 상기 운영체제는 상기 관리자 공간을 위해 단지 한 개의 메모리 문맥을 사용한다고 말할 수 있다.

상기 관리자 주소 공간 맵핑은 정적이거나 동적일 수 있다. 상기 정적 맵핑은 시스템 초기화에 생성되고 일반적으로 (전부 또는 부분적으로) 유효한 물리적 메모리를 맵핑한다. 상기 맵핑은 또한 1대1 또는 커널 가상(KV, kernel virtual) 맵핑을 호출했다. 특히, 상기 KV 맵핑은 일반적으로 운영체제 커널 코드, 데이터 및 bss 섹션을 다룬다. 동적 맵핑은 동적으로 적재된 커널 모듈 또는 동적으로 할당된 (비접촉) 메모리 청크에 접근하기 위해 실시간으로 생성시켰다.

물론, 상기 메모리 문맥(변환 테이블 베이스 레지스터)은 CPU 상에서 실행시키기 위해 상기 나노커널이 새로운 운영체제를 스케줄링할 때 교환해야 한다. 상기 ARM 구조는 메모리 문맥 교환 시간에 동일한 변환식을 사용하는 KV 맵핑 전부를 필요로 하도록 결정한 캐시 앨리어싱(aliasing) 때문에 필요로할 수 있는 상당한 고비용의 캐시 플러쉬를 방지하기 위해 단지 가상 캐시만을 지지한다. 즉, 물리적 메모리 위치의 관리자 주소는 모든 운영체제를 위한 KV 맵핑 전부에 있어서 동일해야 한다. 그것은 동일한 접근 및 캐시 속성을 사용할 것이다. 모든 운영체제는 동일한 사용자 주소 공간을 공유한다고 말할 수 있다 (그러나 상이할 수 있는 변환 트리는 그렇지 않다). 각 운영체제는 상기 관리자 공간 내 전용 공간에서 동작한다. 기술된 요건은 또한 MMU가 존재하지 않을 때에도 당연한 것임을 주지하라.

세 종류의 메모리 문맥은 나노커널 환경으로 구별한다: 주, 보조 및 나노커널 문맥.

상기 주 메모리 문맥은 주 운영체제 커널에 의해 현재 사용되는 메모리 문맥이다. 상기 주 운영체제가 사용자 주소 공간을 지지하는 경우, 상기 주 커널에 의해 사용된 다중 메모리 문맥이 있을 수 있지만, 상기에 이미 언급한 바와 같이, 관리자 주소 공간은 상기 문맥 전부에 있어서 동일하다. 상기 나노커널은 사용자 공간 맵핑에 대해 유념하지 않기 때문에, 상기 주 메모리 문맥은 나노커널 관점에서 유일하고 상기 주 커널에 의해 확립된 정적 및 동적 관리자 맵핑으로 이루어진다.

상기 보조 메모리 문맥은 보조 운영체제 커널에 의해 현재 사용되는 메모리 문맥이다. 그것은 주 메모리 문맥과 유사하다. 그것은 나노커널 관점에서 (특정 보조 커널을 위해) 유일하고 상기 보조 커널에 의해 확립된 정적 및 동적 관리자 맵핑으로 이루어진다.

나노커널의 소유인 운영체제 맵 물리적 메모리 전부를 필요로 하며, 따라서 그들은 상기 나노커널을 직접 호출할 수 있다 (즉, 실행 모드 및 메모리 문맥을 변경하는 트랩 또는 다른 특정 명령 없이, 섹션 2.2를 보라). 그들은 또한 이 방법으로 상기 나노커널에 의해 보내진 데이터 구조에 접근할 수 있다 (운영체제 문맥, 섹션 2.3을 보라).

모든 운영체제는 통신 메커니즘 구현으로부터 상응하는 요구에 의거하여 다른 운영체제의 소유인 일부 물리적 메모리를 맵핑할 수 있어야 한다.

상기 나노커널 메모리 문맥은 나노커널 그 자체에 의해 형성했다. 상기 문맥은 결합된 시스템 이미지와 마찬가지로 모든 운영체제의 소유인 메모리 뱅크 전부를 맵핑한다. 그것은 대부분 나노커널 초기화 단계에서 사용했다.

고려된 메모리 문맥 전부는 동일한 변환식을 사용해야 함을 상기하라.

도1은 상기 주, 보조 및 나노커널 메모리 문맥의 실시예를 나타낸다. 본 실시예에서, 상기 물리적 메모리 사이즈는 128 메가바이트이다. 모든 운영 시스템 및 나노커널은 OxcOOOOOOO로 시작하는 전이된 1 대 1 (KV) 맵핑을 사용한다 (리눅스 가상 주소 공간 커널과 같이).

2.2 나노커널 호출 및 선점

나노커널은 함수 호출을 통해 숨김없이 또는 인터럽트/예외 핸들러를 통해 내재하여 호출했다. 전자의 경우에, 하나의 운영체제 커널은 상기 나노커널을 호출한다고 말한다. 후자의 경우에, 상기 나노커널은 하나의 운영체제를 선점한다고 말한다. 상기 나노커널은 언제나 관리자 주소 공간에서 실행되는 특권 운영체제 코드(privileged OS)로부터 호출했다. 반면에, 상기 나노커널은 커널 제어 하에서 실행되는 사용자 프로세스와 마찬가지로 운영체제 커널 그 자체를 선점할 수 있다.

우선 결합된 시스템 이미지을 부팅시키면, 상기 나노커널이 우선 작동되고 그것은 주 및 보조 운영체제 커널의 실행을 시작한다. 우선, 상기 초기화 단계가 완료되면, 상기 나노커널은 수동적인 역할을 수행한다. 이는 상기 나노커널에서 실행된 코드가 상기 나노커널을 숨김없이 호출하는 주 및 보조 커널로 또는 외부적으로 생성된 동기(즉, 예외) 및 비동기(즉, 인터럽트) 이벤트로 작동시켰음을 의미한다.

ARM 구조에서, 상기 나노커널 호출에 사용된 메커니즘은 상기 주 및 보조 운영체제와 거의 동일하다. 그것은 두 경우 모두에 간접적 기능 함수 호출이다. 다른 한편으로는, 상기 나노커널은 상기 주 및 보조 운영체제를 다른 방법으로 선점한다.

실행 환경 관점에서 보면, 나노커널은 사실상 주 운영체제 커널에 근접해 있다. 그것은 흔히 동일한 메모리 문맥을, 가끔은, 동일한 관리자 스택을 사용한다. 따라서, 상기 나노커널은 상기 주 운영체제와 같이 대략 동일한 유효성을 가진다. 반면, 상기 보조 운영체제 및 상기 보조 커널 오작동에 데헤 몇몇의 보호를 제공하는 나노커널 사이에는 배리어가 있다. 하지만 그러한 보호는 절대적이지 않으며, 보조 커널은 상기 나노커널과 마찬가지로 상기 주 커널을 여전히 고장낼 수 있다는 것을 주의하라.

2.2.1 주 호출

주 운영체제 커널은 간단한 간접 호출에 의해 나노커널을 호출한다. 상기 호출로 메모리 문맥을 교환하지 않는다.

2.2.2 주 선점

실제로, ARM 구조 상의 나노커널의 현 구현은 상기 주 운영체제를 절대 선점하지 않는다. 상기 주 운영체제 선점은 운영체제 사이의 FPU 분배를 위한 나태한 방법을 구현하는데 사용할 수 있다.

2.2.3 보조 호출

보조 운영 체제 시스템 커널은 간단한 간접 호출에 의해 상기 나노커널을 호출한다. 나노커널은 그 자체로 만약 필요하다면 상기 메모리 문맥과 상기 실행 스 택을 교환한다.

2.2.4 보조 선점

보조 운영체제를 선점할 수 있도록 하기 위해 나노커널은 프로세서 예외 테이블 내에서 그만의 저레벨 핸들러를 설치한다. 하나의 인터럽트가 보조 운영체제를 선점할 때, 이들 저레벨 핸들러들은 상기 나노커널 코드로 점프한다. 상기 메모리 문맥은 상기 나노커널이 CPU 상에서 동작하기 위해 다른 운영체제를 스케줄링할 때 숨김없는 교환이 수행될 동안 여전히 변경시키지 않았음을 주의하라.

2.3 운영체제 문맥

나노커널 데이터는 두 개의 카테고리, 범용 및 각 운영체제 데이터로 분리될 수 있다. 상기 범용 데이터는 상기 각 운영체제 데이터가 특정 주 또는 보조 운영체제 커널과 관련된 상태를 유지할 동안 범용 나노커널 상태(예컨대, 나노커널 변환 트리)를 유지한다. 상기 각 운영체제 데이터는 또한 상기 운영체제 문맥을 호출했다.

실제로, 상기 나노커널은 각 운영체제의 두 데이터를 유지한다. 제1 데이터 구조는 운영체제 문맥 그 자체이다. 그것은 공적이고, 어떤 운영체제에서도 가시적이며 상기 나노커널 인터페이스와 협력한다. 운영체제 문맥 전부는 상기 나노커널의 소유인 전용 메모리 뱅크에 배치했다. 상기 운영체제 문맥은 상기 나노커널 인 터페이스와 관련있는 섹션에서 더 자세히 설명했다.

제2 데이터 구조는 나노커널을 위해 제공된다. 그것은 상기 나노커널 실행부에 의해 내부적으로 사용되는 각 운영체제 정보를 포함한다.

3 나노커널 실행부 인터페이스

본 장(章)에서는 주 및 보조 운영체제 커널로 보내진 나노커널 실행부 인터페이스를 설명한다. 그러한 하나의 인터페이스는 상기 나노커널 방법과 마찬가지로 하나의 커널 및 상기 나노커널 (즉, 가시적인 운영체제 문맥) 사이에서 공유된 데이터로 이루어진다. 상기 나노커널 인터페이스는 운영체제 역할 특성이며 (엄밀히 말하면) 그것은 주 및 보조 커널을 위한 것과 상이하다는 것을 주의하라. 반면에, 상기 운영체제의 역할과는 별도로 기술될 수 있는 상기 두 개의 인터페이스 사이에 상당히 주목할만한 교점이 있다.

3.1 운영체제 문맥

도11은 운영체제 문맥을 도시한다.

모든 운영체제 문맥(보조 운영체제와 마찬가지로 주 운영체제도)은 고정된 길이이고 운영체제 id에 의해 지시된 테이블 내에 배치했다. 상기 운영체제 문맥 내에서, 모든 참조는 물리적 주소를 통해 만들어짐을 주의하라. 하나의 운영체제는 참조된 데이터 구조에 접근하기 위해 그러한 하나의 물리적 주소를 (상기 KV 맵핑으로부터) 가상의 주소로 변환시켜야 한다. 도면은 단지 두 개의 커널: 주 및 보조 커널을 가지는 구성을 보여준다.

미결 VEX 및 허용 VEX 필드는 가상 예외(VEX; virtual excptions)의 현재 상태를 반영한다. 상기 가상 예외 구조는 보조 운영체제 커널 실행 모델과 함께 본 명세서에 더 자세하게 설명되어 있다.

tags 필드는 소위 태그 리스트이다. 그것은 부트 정보를 포함하며 부트로더(bootloader)에 의해 주어진다. 상기 나노커널 환경에 있는 상기 태그 리스트는 가상화 되고 모든 운영 시스템 문맥 내에서 반복됨을 주의하라. 다른 태그들 사이에서, 상기 태그 리스트 구조는 상기 부트 시간 변수를 특징짓는 상기 부트 명령을 포함한다. 그러한 변수는 부트 로더 카(boot loader car)가 상기 나노커널 환경 변수를 통과함으로써 주어진다. 상기 명령 라인은 운영체제 특성이다. 상기 나노커널은 그들과 관련된 유일한 변수를 포함하는 운영체제 특정의 명령 라인을 만들기 위해 최초 명령 라인을 분석한다.

RAM info 필드는 RAM 디스크립션 테이블(description table)을 가리킨다. 상기 RAM 디스크립션 테이블은 모든 운영체제 커널에 의해 공유된 범용 데이터 구조이다. 그것은 RAM 자원이 그들 사이에서 분배된 방법을 기술한다.

dev info 필드는 상기 타겟 보드 상에 존재하는 장치 디스크립터의 리스트를 가리킨다. 그것은 상기 장치가 운영체제 사이에서 분배된 방법을 기술하고 있다(장치는 상이한 운영체제에 의해 분배될 수 없다). 상기 보조 운영체제는 보조 운영체제 재시작 중에 호출할 수 있는 셧다운(shutdown) 함수를 기록하기 위해 상기 리스트를 사용한다.

VIL 필드는 미결 하드웨어 인터럽트의 FIFO 리스트이다. 각 엔트리는 인터럽트 id - 작은 정수를 포함한다. 일반적으로 ARM을 바탕으로 한 보드는 상이한 인터럽트 소스(종종 64 초과)의 무한한 수를 사용한다. 따라서 리스트처럼 그러나 비트마스크(bitmask)와는 다르게 미결 인터럽트의 세트를 나타내기로 결정했다. 사실상 상기 필드는 나노커널 그 자체로서는 사용하지 않았다. 그것은 상기 주 및 보조 운영체제 내의 인터럽트 관리를 단순화하기 위해 여기에 배치했다. 상기 나노커널은 인터럽트 관리 목적을 위해 pending VEX(미결 VEX) 및 enabled VEX(허용 VEX) 필드 내에서 단지 interrupt VEX(인터럽트 VEX) 비트만을 사용한다.

상기 pending XIRQ(미결 XIRQ) 필드는 미결 교차 인터럽트의 데이블에 대한 참조이다. 각 엔트리는 운영체제당 32 가능 교차 인터럽트에 상응한다. 상기 테이블은 나노커널 그 자체로서는 사용하지 않았다. 그것은 상기 교차 인터럽트 교환 내에서의 상기 주 및 보조 운영체제를 돕기 위해 문맥 구조에 의해 참조했다. 거기 에는 상기 교차 인터럽트 전달 - cross interrupt VEX(교차 인터럽트 VEX) 전용의 단지 한 개의 가상 예외가 존재한다. 상기 pending XIRQ 테이블은 교차 인터럽트의 수를 32(교차 인터럽트 소스 당 한 개 비트)까지 늘리도록 허용한다. 교차 인터럽트 비트는 상기 소스 운영체제(즉, 상기 교차 인터럽트를 송신하는 운영체제 커널)에 의해 설정(set)했고 목적 운영체제(즉, 상기 교차 인터럽트를 수신하는 운영체제 커널)에 의해 재설정(reset)했다.

ID 필드는 유일한 운영체제 식별자를 포함한다. 식별자 0은 상기 나노커널 그 자체로 지정됐고 식별자 1은 상기 주 운영체제 커널로 지정했다. 상기 운영체제 식별자들은 나노커널 인터페이스 내에서 운영체제를 나타낸다. 예를 들어, 상기 운영체제 식별자는 특정 커널(상기 RAM 디스크립션 테이블에 있는 메모리 청크)로 지정된 자원을 태깅하기 위해 사용했다.

상기 운영체제 문맥의 마지막 부분은 나노커널 인터페이스 방법의 주소로 명시한다. 그들은 상기 KV 맵핑에 있는 주소들이고, 따라서 그들은 어떤 추가적 변환 없이도 나노커널을 호출하는데 사용할 수 있다. 동일한 주소 변환식을 사용해야 하는 KV 맵핑 전부를 상기하라.

상기 나노커널은 주 및 보조 운영체제를 위해 상이한 함수를 보냄을 주의하라. 예컨대, 상기 주 및 보조 시스템이 유휴 방법을 호출할 때, 그들은 사실 두 개 의 상이한 나노커널 함수를 호출한다.

3.2 나노커널 방법

나노커널은 두 그룹의 방법, 콘솔 I/O 방법 및 실행 방법을 제공한다. 상기 콘솔 I/O 그룹은 하나의 커널이 상기 나노커널 콘솔 직렬 라인으로/에서부터 특성을 송/수신하도록 허용한다. 본 명세서는 더 또는 덜 범용인 콘솔 I/O 방법을 특히 겨냥한 것이 아니라 ARM 구조 특성인 실행 방법에 초점을 맞추었다.

3.2.1 예외 핸들러 인스톨

ARM 구조상에서, 상기 예외 테이블은 유일하고 0x00000000 또는 0xffff0000에 배치했다. 상기 나노커널 환경에서, 상기 예외 테이블은 가상화되고, 따라서 예외 벡터를 ARM 예외 테이블에 직접 인스톨 하지 않고 하나의 운영체제는 상기 나노커널 방법을 호출할 것이다. 예외 핸들러 주소와 마찬가지로 상기 예외 숫자(즉, undefined instruction, prefetch abort, data abort 또는 software inturrupt)는 변수처럼 지나간다.

예외 핸들러 주소를 상기 운영체제 문맥 안에 저장했다. 상기 나노커널은 부가적인 간접 호출의 오버헤드를 최소로 하면서 상응하는 예외를 직접 상기 운영체제까지 올리기 위해 나중에 그것을 사용할 수 있다.

ARM 구조 상에서, 상기 예외 테이블은 예외 핸들러의 주소를 포함하지 않으며 오히려 예외 당 하나의 프로세서 명령을 포함한다. 상기 명령은 실제의 예외 핸들러로 점프하는데 사용했다. 상기 나노커널 환경에서, 나노커널 그 자체에 의해 제공되는 매우 작은 프롤로그 코드(prologue code)로 점프한다. 그것은 상기 현재 운영체제 문맥으로부터 예외 핸들러 주소를 읽어들이고 그것으로 점프한다. 상기 현재 작동 문맥 포인터는 프롤로그 코드에 의해 쉽게 접근가능한 범용 변수 내에서 유지됐다. 상기 나노커널은 하나의 새로운 운영체제 커널이 CPU 상에서 실행하도록 스케줄링 될 때 각각의 시간에 상기 변수를 업데이트한다.

이러한 방법으로 상기 예외 핸들러는 기존의 경우(실행 모드 및 레지스터 상태)에서와 같이 동일한 실행 환경에서 호출했다. 배열된 스택 포인터 레지스터는 undefined instruction, prefetch abor 및 data abort 핸들러를 위한 나노커널 프롤로그 코드에 의해 스크래치 했다. 상기 software interrupt 핸들러를 위한 배열된 스택 포인터 레지스터는 원 상태를 유지했다.

3.2.2 인터럽트 핸들러 인스톨

상기 나노커널 방법은 직접 및 간접 interrupt VEX 핸들러를 인스톨 하는데 사용했다. 그들의 주소는 변수처럼 지나간다.

상기 직접 인터럽트 핸들러는 상기 예외 핸들러와 유사하다. 그들은 단지 주 운영체제로서 사용했고 이는 그것이 CPU 상에서 작동하는 동안 하드웨어 인터럽트를 관리하기 위함이다. 상기 직접 인터럽트 핸들러는 기존의 경우(실행 모드 및 레지스터 상태)에서와 같이 동일한 실행 환경에서 호출했다.

상기 간접 인터럽트 핸들러는 다른 운영체제 커널에 의해 전달된 인터럽트를 관리하기 위해 상기 나노커널로 호출했다. 그들은 상기 직접 인터럽트 핸들러에 비해 약간 상이한 실행 환경 내에서 호출했다. 그들은 본 명세서에서 더 자세히 기술했다.

3.2.3 교차 인터럽트 핸들러 인스톨

나노커널은 실재 CPU 상에 존재하지 않는 추가적 가상 예외를 지지한다. 그것은 하나의 교차 인터럽트 VEX이다. 그것은 운영체제간 통신의 초석이다. 상기 교차 인터럽트는 정규 인터럽트와 매우 유사하지만, 하나의 하드웨어 장치 대신 하나의 운영체제로 증가시켰다.

상기 나노커널 방법은 상응하는 교차 인터럽트 핸들러를 기억하는데 사용했다. 그것을 간접 인터럽트 핸들러와 같이 동일한 실행 환경(실행 모드 및 레지스터 상태) 내에서 호출했다.

3.2.4 교차 인터럽트 포스트

상기 나노커널 방법은 목적 운영체제 상에서 cross interrupt VEX(교차 인터럽트 VEX)를 증가시키는데 사용했다. 그것은 또한 상기 미결 XIRQ 테이블 내에서 상응하는 비트를 설정한다. 상기 목적 운영체제 id 및 교차 인터럽트 숫자는 변수처럼 지나간다.

3.2.5 유휴

상기 나노커널은 유휴 루프 내에서 하나의 운영체제 커널에 의해 호출되어야 할 유휴 방법을 제공한다. 그것은 상기 호출 운영체제 커널이 다음 인터럽트까지 할 일이 없음을 나노커널에게 알린다.

상기 유휴 방법 호출은 결과적으로 보조 운영 커널을 작동시킬 준비가 되었거나 (만약에 있다면) 또는 보조 운영체제 커널 전부가 유휴할 때 상기 주 유휴 방법으로부터 리턴되는 동안에 그 다음으로 시스템 교환이 일어난다.

상기 나노커널은 주 유휴 방법을 위한 두 개의 상이한 구현, 즉, 스테이트리스(stateless) 및 스테이트풀(statefull)을 제공한다. 상기 스테이트리스 유휴 방법으로부터 돌아올 때, 모든 레지스터들은 스크래치이다. 상기 스테이트풀 유휴 방법으로부터 돌아올 때, 영구 레지스터들{r4-r13}을 보존한다.

상기 유휴 방법의 올바른 구현은 상기 주 운영체제 유휴, 루프 구현에 달려 있고 관련있는 구성 .xml 파일에서 선택할 수 있다.

3.2.6 재시작

나노커널은 하나의 보조 운영체제 커널을 재시작하기 위해 하나의 보조 운영체제와 마찬가지로 상기 주 운영체제에 의해 호출될 수 있는 재시작 방법을 제공한다. 재시작된 상기 운영체제의 id는 변수처럼 지나간다.

상기 나노커널은 상기 목적 운영체제 실행을 정지시키고, 사본으로부터 상기 운영체제 커널 이미지를 복원시키며 최종적으로 첫 엔트리 지점에서 상기 운영체제 커널 실행을 시작한다.

3.2.7 보조 정지

정지 방법은 하나의 보조 운영체제로의 상기 나노커널에 의해 제공했다. 상기 나노커널은 나노커널 스케줄러 내에서 교환되는 것을 방지하기 위해 비실행 상태로 작동중인 호출기를 배치한다.

정지된 운영체제는 상기의 기술된 재시작 나노커널 방법에 의해 다시 시작시킬 수 있었다.

4 주 실행 환경

기본적으로, 주 운영체제 커널은 기존 실행 환경 내에서 실행된다. ARM 프로세서 상에서의 상기 나노커널 구현은 상기 주 운영체제 특성(성능, 인터럽트 대기 시간, 선점 대기시간)에 대한 나노커널 환경의 충돌을 최소화하기 위해 노력한다. 주 운영체제는 일반적으로 실시간 운영체제이기 때문에, 만약 다른 (보조) 운영체제가 상기 동일한 프로세서 상에서 동시에 실행될지라도 상기 주 커널 상태가 변하지 않도록 유지하는 것이 중요하다.

4.1 초기화

주 운영체제는 작동 프로세서 초기화를 실행하고, (만약 필요하다면) RAM에 있는 나노커널 데이터를 인스톨하고, 하나의 초기화 번역 트리를 준비하고, (만약 존재한다면) MMU를 허용하고 상기 나노커널 엔트리 지점으로 점프하는 작은 trampoline 프로그램을 제공한다. 상기 초기화 변환 트리는 상기 trampoline 프로그램 및 나노커널을 맵핑할 것이다. 실행 모드는 사용자 모드이고, 모든 하드웨어 인터럽트는 허용하지 않았다.

제 차례에 상기 나노커널은 상기 RAM 안에 운영체제 메모리 뱅크를 인스톨하고, 운영체제 문맥을 초기화하며 (만약 그것이 존재한다면) 허용 MMU와 함께 상기 주 엔트리 지점으로 점프하고 하드웨어 인터럽트를 허용하지 않았다. 상기 실행 모드는 여전히 사용자 모드이다.

상기 나노커널 초기화 코드는 그의 데이터 섹션에 위치하는 정적 나노커널 스택을 사용하여 실행했다. 상기 주 운영체제로 점프할 때, 상기 스택은 여전히 유효하다. 그럼에도 불구하고, 상기 주 운영체제 커널은 가능한 빨리 그 자신의 스택으로 교환되어야 하고 후에 상기 나노커널 스택을 사용하여서는 안된다. 나노커널 스택은 다음 장에 설명될 바와 같이 보조 호출 및 선점을 관리하기 위해 초기화 단계뿐 아니라 실시간에 사용했다.

상기 주 운영체제 커널로 점프할 때, 스택 포인터 레지스터 배열된 상기 사용자 모드는 상기 주 운영체제 문맥을 지시한다. 프로세서 인터럽트는 상기 주 초기화 단계의 시작 부분에 허용하지 않았다. 상기 주 운영체제 커널은 일반적으로 핵심 초기화 단계가 한 번 완료될 때 허용한다.

초기화 상태 중에, 상지 주 운영체제 커널은 일반적으로 예외 및 인터럽트 핸들러를 셋업하기 위해 상기 나노커널 방법을 호출한다. 최종적으로 상기 주 커널은 상기 유휴 루프로 들어가고 상기 나노커널 유휴 방법을 호출한다.

상기 유휴 방법이 처음 호출될 때, 상기 나노커널은 상기 주 운영체제 커널이 완전히 초기화된 그의 실행 환경을 가지며 그것이 포스트 초기화 상태로 포스트 초기화 상태를 시작함을 고려한다.진행하는지를 고려한다.

상기 포스트 초기화 상태에서, 상기 나노커널은 상기 나노커널 메모리 문맥을 완성시킨다. 그것은 RAM info 필드에 의해 지시된 관련있는 디스크립터 내에서 모든 유효한 물리적 메모리를 발견하고 저장하기 위한 주 운영체제의 의무이고, 따라서 상기 나노커널은 그것의 메모리 문맥을 완성할 수 있음을 주지하라. 한 번 상기 포스트 초기화가 완료되면, 상기 나노커널은 동작할 준비가 된 보조 커널과 교환하기 위해 또는 만약 모든 보조 커널이 유휴라면 상기 주 유휴 방법으로부터 돌아오기 위해 상기 스케줄러를 호출한다.

상기 나노커널은 범용으로 분배된 구조, RAM 디스크립터 및 장치 리스트를 초기화하기 위해 주 운영체제를 필요로 한다. 그러한 초기화는 상기 유휴 방법이 호출되기 전에 완료해야 한다. 상기 요구는 그러한 순간을 넘어서 보조 커널이 범용으로 분배된 데이터 구조로 접근할 수 있기 때문에 당연한 것이다.

특히, 상기 주 커널은 상기 보드 상에서 유효한 물리적 메모리를 감지하고 상기 RAM 디스크립터 내에서 자유 물리적 메모리 청크를 저장할 책임이 있다.

상기 주 보드 지지 패키지(BSP; Board Support Package)에 따라, 상기 주 커널은 특히 하나의 인터럽트 제어기 드라이버에서 나노커널 감지 드라이버를 시작시켜야 한다.

4.2 주 예외

기본적으로, 상기 나노커널은 상기 주 운영체제가 상기 프로세서상에 실행될 때 발생되는 예외를 인터셉트하지 않는다. 프로그래밍 예외 전부는 기계어 주 핸들러로 관리했다. 나노커널은 상응하는 예외 핸들러로 점프하기 위해 단지 작은 프롤로그 코드만 실행시킨다. 상기 저-레벨 핸들러는 상기 ARM 나노커널 구조로 이식할 때 수정할 필요가 없다.

배열된 스택 포인터 레지스터는 undefined instruction , prefetch abort 및 data abort 핸들러를 위한 상기 나노커널 프롤로그 코드로 스크래치했다. software interrupt 핸들러를 위한 상기 배열된 스택 포인터 레지스터는 그대로 유지되었다.

4.3 주 인터럽트

주 운영체제가 CPU 상에서 실행하는 동안 하나의 인터럽트가 발생할 때, 기계어 저레벨 (직접) 인터럽트 핸들러는 상기 나노커널에 의해 도입된 어떤 추가적인 코드 없이도 호출했다. 상기 배열된 스택 포인터 레지스터는 그대로 유지되었다.

4.4 전달된 인터럽트

보조 운영체제가 프로세서 상에서 실행하는 동안 하나의 인터럽트가 발생할 때, 그것은 주 운영체제로 전달됐다. 그러한 하나의 인터럽트는 하기의 주 단계를 따르는 관리를 전달한다:

。 상기 인터럽트를 상기 나노커널로 인터셉트;

。 선점된 보조 운영체제 커널의 실행을 보류하고 상기 나노커널은 주 실행 환경과 교환;

。 상기 나노커널은 상기 주 운영체제 커널로 상응하는 인터럽트를 트리거한다.

상기의 방법에서, 상기 상응하는 주 저레벨 간접 인터럽트 핸들러는 상기 인터럽트를 관리하기 위해 (상기 주 실행 환경 내에서) 호출했다. 한 번 상기 인터럽트 핸들러가 관리되면, 상기 주 운영체제 커널은 상기 나노커널로 돌아간다.

상기 주 간접 인터럽트 핸들러로부터 돌아온 뒤, 상기 나노커널은 다음 보조 운영체제가 작동하도록 결정하기 위해 그의 스케줄러를 호출한다. 상기 선점된 보조 시스템은 인터럽트 이후에 계속될 필요가 없음을 주의하라. 다른 (더 높은 우선 순위의) 보조 시스템은 상기 인터럽트를 이유로 동작할 준비를 할 수 있다.

ARM 구조 상에서, 상기 CPU는 user , system , supervisor , undefined , abort, interrupt 및 fast interrupt의 7개의 다른 실행 모드에서 동작할 수 있다. 그들 중 5개는 그들의 공급/배열된 r13 및 r14 레지스터를 가진다. 따라서 원칙적으로, 상기 나노커널이 하나의 운영체제 커널에서 다른 하나로 교환할 때 배열된 레지스 터 전부도 교환되어야 한다. 상기 운영체제 교환 및 인터럽트 전달의 속도를 증가시키기 위해 우리는 스크래치와 같이 관리자 레지스터를 제외한 배열된 레지스터 전부를 고려하기로 결정했고, 우리는 또한 상기 관리자 모드에서 그러한 교환을 항상 실행하도록 결정했다.

만약 보조 시스템이 상기 사용자 모드에서 동작하는 동안 하나의 인터럽트가 발생한다면, 상기 상응하는 배열된 스택 레지스터는 상기 인터럽트 핸들러에 의해 보존될 것이고, 이는 그것이 항상 이전 상태를 보존하기 때문이다. 만약 상기 보조 시스템이 상기 관리자 모드에서 동작하는 동안 하나의 인터럽트가 발생하면, 상기 사용자 모드의 배열된 레지스터는 항상 상기 운영체제 그 자체에 의해 저장될 것이다.

우리의 요구를 만족시키는 가장 쉬운 방법은 상기 보조 운영체제 예외 핸들러를 수정하는 것이다. 그들은 항상 미리 정해진 값으로 상기 배열된 스택 포인터 페지스터를 설정하고 되도록 빨리 상기 관리자 모드로 교환해야 한다. 상기 하드웨어 인터럽트는 단지 상기 관리자 모드로의 교환이 완성될 때에만 허용했다.

상기 주 운영체제가 실행되는 동안 상기 CPU 실행 모드 상에는 제한이 없는데, 이는 상기 운영체제의 교환이 그러한 상황에서 발생될 수가 없기 때문이다.

나노커널이 상기 주 운영체제 커널로 하나의 인터럽트를 전달할 때, 그것은 하나의 주 간접 인터럽트 핸들러를 호출한다. 그것은 이미 상기 운영체제 문맥에 저장된 r10-r15 및 cpsr 레지스터와 함께 관리자 모드 내에서 호출했다. r10은 상기 문맥에 대한 포인터를 포함한다. 구성에 의해, 상기 나노커널이 하나의 인터럽트를 그것으로 전달할 때, 상기 주 운영체제는 항상 비활동 상태에 있다(즉, 그것은 유휴 나노커널 방법을 호출했다).

하나의 간접 인터럽트 핸들러 실행의 결과처럼 상기 주 운영체제는 새로운 작업을 스케줄 할 수 있고, 따라서 만약 그것이 스테이트리스 유휴 루프를 실행시킨다면 (만약 그것이 상기 유휴 상태 내에 호출되거나 유휴 루프 레지스터를 저장함 없이 단순히 새로운 작업과 교환할 때 그것이 모든 레지스터를 보존하는 하나의 인터럽트 핸들러를 요구하지 않는다면), 상기 나노커널은 상기 운영체제 문맥 내에서 모든 레지스터 (및 단지 r10-r15)를 저장해야 한다. 상기 나노커널이 상기 보조 운영체제로 되돌아가서 교환할 때 그들을 복원시킬 것이다.

만약 하나의 주 운영체제가 하나의 스테이트풀 유휴 루프를 실행한다면 (예컨대, 만약 하나의 유휴 루프는 통상적인 저 우선 순위 작업과 같이 실행되고 하나의 운영체제 스케줄러가 인터럽트 관리의 말단에서 바로 호출되었다면), 상기 주 운영체제에 의해 보존될 것이기 때문에, 우리는 r0-r9 레지스터의 저장을 연기할 수 있다. 상기 나노커널은 단지 상이한 보조 운영체제를 스케줄 할 때에만 그들을 저장/복원시켜야 한다. 만약 우리가 상기 나노커널 환경에서 단지 두 운영체제(하나는 주, 하나는 보조)만을 실행시킨다면 r8-r9 레지스터 저장은 완전히 피할 수 있다.

상기 나노커널은 (모든 레지스터가 하나의 간접 인터럽트 핸들러 호출보다 먼저 저장될 때) 일반적인 (최적화되지 않은) 인터럽트 전달 및 최적화된 것 둘 모두를 지지한다. 올바른 구현은 상기 주 운영체제에 의존하며 관련있는 구성 .xml 파일 내에서 선택할 수 있다.

5 보조 실행 환경

기본적으로, 보조 운영체제 커널 실행 환경은 상기 인터럽트 관리를 제외한 기계어의 그것과 거의 근접하다. 상기 나노커널 환경은 다른 운영체제에 의해 완전히 선점할 수 있는 하나의 보조 운영체제를 만들기 위해 상기 인터럽트 관리의 기계어 메커니즘을 수정한다. 하나의 보조 운영체제 커널은 프로세서 레벨에서 더이상의 인터럽트를 허용하지 않고 상기 나노커널(즉, 가상 예외)에 의해 제공되는 하나의 소포트웨어 인터럽트 메커니즘을 사용하는 상기 나노커널 구조로 내보내진다. 인터럽트들은 그러한 보조 운영체제 커널에 의해 더이상 바로 관리되지 않고, 상기 나노커널에 의해 인터셉트되고 상기 주 운영체제 커널로 전달했다. 그 순서에 상기 주 운영체제는, 만약 필요하다면, 상기 보조 운영체제를 위한 하나의 interrupt VEX를 일으킬 것이다. 상기 interrupt VEX는 만약 그것이 금지 해제되면 보조 간접 인터럽트 핸들러에 의해 곧바로 관리할 것이며 만약 그것이 금지되었다면 연기할 것이다.

5.1 초기화

상기 나노커널은 보조 뱅크와 함께 초기화 시간에 상기 보조 메모리 뱅크를 인스톨한다. 반면에, 보조 커널의 최종 초기화는 포스트 초기화 단계까지 연기했다.

상기 단계에서, 나노커널은 보조 메모리 뱅크의 사본을 유지하기 위해서 메모리를 할당한다. 그러한 사본은 곧 재시작 시간에 보조 시스템의 초기 이미지를 복원하는데 사용했다. 그러나 상기 보조 시스템 재시작은 옵션이고 상기 물리적 메모리 소비를 줄이기 위해서 허용하지 않을 수 있다.

상기 주 커널과 유사하게, 상기 운영체제 문맥은 관리자 모드 배열된 스택 포인터 레지스터 내에서 지나갔다. 한편, 상기 주 커널과는 달리, 하드웨어 인터럽트는 보조 커널 초기화 단계 중이라도 허용했다. 분명히, 상기 상응하는 보조 interrupt VEX는 허용되지 않았다. 보조 커널 초기화 코드일지라도 상기 주 시스템에 의해 완전히 선점할 수 있음을 주지해야 한다. 이것은 특히 하나의 보조 운영체제가 재시작 될 때 상기 주 운영체제를 방해하지 않도록 하기 위해서 중요하다.

허용 하드웨어 인터럽트에도 불구하고, (하드웨어 인터럽트에 상응하는) 상기 가상 예외는 하나의 보조 커널이 시작될 때 허용하지 않았다. 따라서, 인터럽트들은 그들이 상기 핵심 초기화 단계의 말단에서 상기 커널에 의해 숨김없이 허용될 때까지 전달하지 않았다. (가상 예외에 바탕을 둔) 상기 소프트웨어 인터럽트 금지 메커니즘은 본 명세서에서 더 상세히 설명했다.

상기 보조 운영체제는 허용 MMU와 함께 시작했다. 상기 나노커널 문맥은 초기화 메모리 문맥처럼 사용했다. 그러한 초기 1 대 1 맵핑은 보조 커널로 일시적으로 제공했다. 상기 맵핑을 수정해서는 안되고 상기 초기화 코드에 의해 영구적으로 사용해야 하며, 대신, 상기 보조 커널은 그만의 KV 맵핑을 형성하고 가능한 빨리 그것으로 교환해야 한다.

일반적으로, 상기 보조 커널은 그것의 초기화 코드를 실행하기 위해 상기 데이터 섹션에 배치된 정적 초기 스택을 사용한다.

상기 주 커널과 유사하게, 상기 초기화 단계 동안, 하나의 보조 커널은 일반적으로 예외 및 인터럽트 핸들러를 인스톨하기 위해 상기 나노커널을 호출한다. 최종적으로, 상기 보조 커널은 상기 유휴 루프 안으로 들어가고 상기 나노커널 유휴 트랩을 호출한다.

5.2 보조 예외

기본적으로, 상기 나노커널은 상기 보조 운영체제가 상기 프로세서 상에서 실행될 때 발생하는 인터셉트를 인터셉트하지 않는다. 프로그래밍 예외 전부는 기계어 보조 예외 핸들러로 관리했다. 상기 나노커널은 관련있는 예외 핸들러로 점프하기 위해 단지 하나의 작은 프롤로그 코드를 실행시켰다. 그들은 상기 ARM 나노커널 구주로 이식할 때 수정할 필요가 없는 보조 저레벨 핸들러이다.

상기 배열된 스택 포인터 레지스터는 undefined instruction , prefetch abort 및 data abort 핸들러를 위한 나노커널 프롤로그 코드에 의해 스크래치했다. 상기 소프트웨어 인터럽트 핸들러를 위한 상기 배열된 스택 포인터 레지스터를 그대로 유지했다.

5.3 가상 예외

가상 예외(VEX; Virtual exceptions)는 하나의 예외를 하나의 운영체제 커널로 포스트하고 그것을 연기된 방법으로 전달하도록 허용하는 상기 나노커널에 의해 제공되는 메커니즘이다. 특히, 상기 VEX 메커니즘은 하나의 보조 운영체제 커널을 위한 소프트웨어의 인터럽트로 하드웨어 인터럽트를 대신하기 위해 상기 ARM 나노커널 구조 내에서 사용했다.

상기 VEX 인터페이스는 커널 문맥 내에 배치된 두 개의 필드, 미결 및 허용으로 이루어진다. 상기 필드들은 단지 하나의 보조 운영체제에 대해서만 의미가 있지만, 상기 주 및 보조 운영체제 커널 모두에 의해 접근했다.

가상 예외 전부는 pending (또는 enabled) 필드 내에서 비트 위치에 의해 자연적으로 열거했다. 따라서, 상기 ARM 구조 상에 총 32개의 가능한 가상 예외가 있다(상기 pending 및 enabled 필드는 32 비트 정수 값).

ARM 구조 상에 상기 나노커널에 의해 지지되는 가상 예외는 단지 4개가 있다: interrupt, fast interrupt, cross interrupt 및 "running".

하기의 표는 상기 가상 예외가 실재의 그것으로 맵핑하는 방법을 보여준다:

가상 예외	디스크립션
0	"running"
8	interrupt VEX
16	fast interrupt VEX
24	cross interrupt VEX

상기 가상 예외 "running"은 어떤 실재 예외와도 관련되지 않으며 그것은 사실 상기 커널이 유휴인지 감지하기 위해 상기 나노커널에 의해 내부적으로 사용한 슈도(pseudo) 가상 예외이다.

다중 가상 예외는 동시에 미결될 수 있고 , 단지 그들 중 하나만이 동시에 관리될 수 있기 때문에, 모든 가상 예외는 그의 수에 따라 우선 순위를 매긴다. 가장 높은 우선 순위는 상기 fast interrupt VEX로 할당정했고 가장 낮은 우선 순위는 상기 " running " VEX로 할당했다.

보조 문맥의 pending VEX 필드는 일반적으로 상기 인터럽트 제어기를 위한 하나의 드라이버를 제공하는 주 커널에 의해 업데이트했다. 그러한 하나의 드라이버는 일반적으로 상기 pending VEX 필드에 있는 적합한 비트를 설정함으로써 보조 커널로 가상 예외를 포스트한다.

enabled VEX는 가상 예외를 허용 또는 비허용하기 위해 상기 보조 커널에 의해 업데이트했다. 특정 가상 예외는 만약 상응하는 비트가 상기 enabled VEX 필드 내에서 설정된다면 허용한다. 상기 enabled VEX 필드를 사용하여, 보조 커널은 인터럽트에 대해 보호된 핵심 섹션을 실행한다. 즉, 하나의 보조 커널은 비허용/허용 프로세서 인터럽트에 대해 CPSR 레지스터를 더이상 다루지 않고, 오히려 그의 커널 문맥의 enabled VEX 필드를 수정한다.

특정 가상 예외는 그것이 동시에 미결이고 허용된다면 상기 나노커널에 의해 전달했다. 상기 나노커널은 상기 VEX 핸들러로 점프하기 바로 직전에 상응하는 미결 비트를 재설정했다.

VEX 핸들러 전부는 사실상 간접 핸들러임을 주지하라. 그들은 상기 운영체제 문맥에 이미 저장된 cpsr 레지스터 및 r10-r15와 함께 상기 관리자 모드에서 상기 나노커널에 의해 호출했다.

상기 ARM 나노커널 구조 상에서 하나의 보조 커널을 내보낼 때, 저레벨 예외 핸들러는 하드웨어 인터럽트를 대체하는 메커니즘을 금지하는 소프트웨어 인터럽트를 고려하기 위해 여전히 수정되어야 한다. 하나의 인터럽트 핸들러를 호출할 때, 상기 나노커널은 단지 enabled 필드에 대해 상응하는 값을 쓰는 모든 가상 예외를 허용하지 않는다. 상기 하드웨어 인터럽트는 항상 보조 운영체제 상에서 실행될 때 프로세서 레벨에서 허용했고 따라서 그것은 하나의 저레벨 인터럽트 핸들러 내부에서조차 상기 주 운영체제에 의해 선점할 수 있었다.

하나의 가상 예외는 비허용 상태 동안 상기 주 운영체제 커널에 의해 포스트시킬 수 있다. 이 경우, 상기 예외는 상기 보조 운영체제 커널로 전달하지 않았고, 오히려 가상 예외를 재허용할 때까지 미결을 유지시켰다. 따라서, 가상 예외가 하나의 보조 운영체제 커널에 의해 재허용될 때, 어떤 가상 예외가 미결인지 체크해야 한다. 만약 그 체크가 명백하다면, 상기 보조 운영체제 커널은 그러한 미결 가상 예외를 관리하기 위해 상기 나노커널을 호출해야 한다.

일반적으로, 하나의 보조 커널은 가상 예외를 하기의 두 경우에 재허용한다:

。가상 예외가 코드의 핵심 섹션을 보호하기 위해 상기 보조 커널에 의해 이전에 허용되지 않을 때

。가상 예외가 간접 인터럽트 핸들러 호출의 결과에 따라 상기 나노커널에 의해 허용되지 않을 때

5.4 나노커널 재진입

상기 나노커널 코드는 상기 나노커널 안으로 재진입하는 것을 방지하는 프로세서 레벨에서 비허용된 인터럽트와 함께 대부분 실행시켰다. 반면에, 나노커널 호출의 일부는 시간이 오래걸릴 수 있고 따라서 상기 나노커널은 주 인터럽트 대기시간을 적게 유지하기 위해 상기의 긴 작업을 실행할 때 인터럽트들을 허용해야 한다.

두 종류의 긴 나노커널 작업이 있다:

。동기 콘솔 출력

상기 작업 기간은 직렬 라인 속도에 의존한다. 예컨대, 9600 baud 비율 라인상에서, 단일 문자 출력은 1 밀리 초까지 걸릴 수 있다.

。보조 커널 재시작

상기 작업 기간은 하나의 사본으로부터 복원된 상기 커널 이미지 크기에 의존한다.

상기에 열거한 모든 작업을 위해, 상기 나노커널은 인터럽트를 허용하고 따라서 상기 주 커널로부터 재진입한다. 한 편, 인터럽트들이 허용되는 동안, 상기 나노커널 스케줄러는 상기 주 인터럽트 핸들러로부터 되돌아올 때 다른 보조 커널이 스케줄링되는 것을 막기 위해 허용하지 않았다. 즉, 인터럽트가 허용되는 동안, 나노커널 스케줄러는 상기 주 인터럽트 핸들러로부터 돌아올 때 다른 보조 커널을 스케줄하기 위해 허용하지 않았다. 즉, 상기 나노커널은 (하나의 인터럽트의 결과에 따라) 단지 상기 주 커널에 의해 선점할 수 있지만 보조 커널로부터의 재진입은 금지했다. 그러한 제한은 상기 나노커널이 보조 실행 환경을 위해 범용 자원을 사용하도록 허용한다.

보조 커널로부터 발생된 일부 긴 작업은 상기 주 메모리 문맥에서 실행할 수 있다. 즉, 그러한 작업을 실행하기 전에, 상기 나노커널은 상기 주 실행 문맥과 교환하고 곧 인터럽트를 허용한다. 한 번 상기 작업이 완료되면, 나노커널은 인터럽트를 허용하지 않고 상기 나노커널 스케줄러를 통해 호출기 보조 커널로 돌아간다.

또한 상기 주 실행 환경으로/으로부터의 교환에 의해 소개된 여분의 오버헤드를 막기 위해 (그들은 주 메모리 문맥에서조차 실행될 수 있다) 상기 나노커널 메모리 문맥에서 종종 사용된 나노커널 방법을 실행하기 위해 바람직함을 주지하라. 그러한 빈번한 작업의 특정한 실시예는 상기 나노커널 콘솔 상의 동기 출력이 다.

6 스케줄 러

운영체제 스케줄러의 주된 역할은 동작할 다음 작업을 선택하는 것이다. 상기 나노커널이 운영체제의 실행을 제어하기 때문에, 상기 나노커널 스케줄러는 동작할 다음 보조 운영체제를 선택한다. 즉, 상기 나노커널은 시스템 전체에 여분의 스케줄링 레벨을 추가한다.

상기 나노커널 구조에서, 주 운영체제는 보조 커널에 대해 높은 우선 순위 레벨을 가지며 CPU는 상기 주 시스템이 단지 유휴 루프에 있을 때에만 주어짐을 주의하라. 우리는 상기 주 커널이 선점할 수 없으며 상기 유휴 루프 내에서 호출된 상기 유휴 방법을 통해 나노커널 스케줄러를 숨김없이 호출한다고 말할 수 있다. 하나의 보조 시스템을 실행할 때 한 번 인터럽트가 발생하면, 상기 주 커널 인터럽트 핸들러을 호출한다. 주 커널 관점에서부터, 그러한 인터럽트는 상기 유휴 루프를 실행하는 배경 스레드(thread)를 선점한다. 한 번 상기 인터럽트를 관리하고 모든 작업이 완료되면, 상기 주 커널은 작동시킬 다음 보조 시스템을 결정하기 위해 상기 나노커널 스케줄러를 호출하는 나노커널로 돌아간다. 보조 활동은 주 커널을 위해 명백하며 상기 주 시스템의 상태를 변경시키지 않는다.

상기 나노커널은 상이한 스케줄링 방법을 실행할 수 있다. 하지만 디폴트에 의해, 알고리즘에 기반을 둔 우선 순위를 사용했다. 동일한 우선 순위 레벨에서, 상기 나노커널은 라운드 로빈(round- robin) 스케줄링 방법을 사용함을 주지하라. 특정 보조 커널의 우선 순위는 시스템 이미지 형성 시간에 정적으로 구성했다.

어떤 스케줄링 방법이 실행되었던 간에, 상기 스케줄러는 특정 보조 시스템이 동작할 준비가 되었는지 감지해야 한다. 상기 조건은 비트의 논리와 같이 그리고 상기 커널 문맥의 pending VEX 및 enabled VEX 필드 사이의 동작으로서 연산했다. 제로가 아닌 결과는 상기 시스템이 작동할 준비가 돼있음을 나타낸다.

상기에 설명된 바와 같이, pending VEX 및 enabled VEX 쌍에 있는 각 비트는 하나의 가상 예외를 나타낸다. 작동할 준비가 된 기준을 재표현할 때, 만약 적어도 하나의 마스크되지 않은 미결 가상 예외가 있다면 우리는 보조 시스템이 작동할 준비가 된 상태에 있다고 말할 수 있다.

일반적으로 하드웨어 및 소프트웨어 (교차) 인터럽트로 맵핑된 모든 가상 예외 사이에서, 상기 커널이 현재 유휴인지 반영하는 (실행하는) 특수한 가상 예외가 있다.

상기 running 비트는 보조 커널이 유휴 방법을 호출할 때마다 pending VEX 필드에서 클리어시켰고 상기 running 비트는 가상 예외가 보조 커널에 전달될 때마 다 pending VEX 필드에서 설정했다.

상기 running 비트는 실행되는 보조 커널을 위해 일반적으로 항상 enabled VEX 필드 내에 설정했다. 상기 나노커널은 하나의 보조 커널이 재시작 될 때 이들 비트를 설정하고 하나의 보조 커널이 정지할 때 이들 비트를 재설정한다. 상기 보조 커널은 금지/비금지 인터럽트가 가상 예외로 맵핑 될 때 상기 running 비트를 절대 클리어해서는 안된다.

하나의 외부 에이전트는 커널 문맥에서 enabled VEX 필드를 클리어/복원함으로써 하나의 보조 커널의 실행을 보류/재개할 수 있음을 주의하라. 상기 특징은, 주 커널 작업과 같이, 상기 나노커널의 외부에서 실행될 스케줄링 방법 에이전트를 위한 가능성을 열어둔다. 게다가, 이는 또한 상기 주 커널의 상부에서 하나의 작업처럼 실행될 하나의 보조 커널을 위한 디버그 에이전트를 허용한다. 그러한 보조 디버그 에이전트의 이점은 상기 주 운영체제에 의해 제공된 모든 서비스가 디버깅을 위해 유용하게 되고 (예컨대, 네트워킹 스택) 보조 커널 디버깅은 상기 주 운영체제 상에서 실행되는 핵심 작업과 함께 동시에 완료할 수 있다.

7 교차 인터럽트

본 섹션은 대부분 상기 나노커널 교차 인터럽트 메커니즘과 관련되는 (이미 이전 섹션에 주어진) 정보를 정리한다.

하기의 교차 인터럽트 두 종류가 여기서 고려될 것이다:

。하나의 보조 운영체제 커널로 송신된 하나의 교차 인터럽트

。하나의 주 운영체제 커널로 송신된 하나의 교차 인터럽트

목적 보조 운영체제로 하나의 교차 인터럽트를 송신하기 위해, 소스 운영체제 커널은 맨 처음 상기 운영체제 문맥의 pending XIRQ 필드를 가리키는 상기 교차 인터럽트 표에서 상응하는 하나의 비트를 설정한다. 곧이어 상기 소스 운영체제 커널은 상기 목적 운영체제 문맥의 pending XIRQ 필드 내에서 상응하는 비트를 설정하는 목적 운영체제로 cross interrupt VEX를 포스트한다. 나노커널에 의해 교차 인터럽트 핸들러가 호출되면, 그것은 pending XIRQ 필드를 체크하고, 상기 미결 교차 인터럽트 소스에 상응하는 비트를 클리어하고 마지막으로 상기 소스에 부착된 핸들러를 호출한다. 소스 및 목적 운영체제 커널 둘 다 pending XIRQ 필드를 업데이트하기 위해 미세한 명령을 사용한다. 상기 동일한 알고리즘은 소스 운영체제 커널의 두 종류, 주 및 보조를 사용했음을 주지하라.

상기 주 운영체제로 하나의 교차 인터럽트를 송신하기 위해, 보조 운영체제 커널은 먼저 상기 운영체제 문맥의 pending XIRQ 필드에 의해 지시되는 상기 교차 인터럽트 표에 상응하는 하나의 비트를 설정한다. 상기 나노커널은 곧바로 보조 운영체제를 선점하고 상기 pending XIRQ 필드를 체크하는 상기 주 저레벨 교차 인터 럽트 핸들러를 호출하고, 상기 미결 교차 인터럽트 소스에 상응하는 비트를 클리어하며 최종적으로 상기 소스에 부착된 핸들러를 호출한다.

상기 교차 인터럽트 숫자 영(zero)은 운영체제 커널에 의해 사용되면 안된다. 상기 인터럽트는 운영체제, 즉 정지된 운영체제가 시작되었거나 실행중인 운영체제가 정지되었음을 포스트하기 위해 상기 나노커널을 위해 보류했다. 다시 말하면, 상기 교차 인터럽트 숫자 영는 실행중인 운영체제, 즉 상기 범용 시스템 구성이 변경되었음을 포스트한다. 그것은 상기 running 필드의 상태가 하나의 운영체제 문맥 내에서 변경되었음을 각각의 시간에 모든 실행중인 운영체제로 명백히 예측됐다.

다른 측면들과 실시예들

전술한 실시예는 다만 사례일 뿐이고 많은 다른 실시예가 가능하다는 것은 명세서 서두에서부터 분명할 것이다. 앞서 언급한 운영체제, 플랫폼과 프로그래밍 기법은 자유로이 변경될 수 있다. 당업자에게 자명한 모든 다른 변경, 치환이나 변형물은 다음의 청구항에 기재되었는지 여부에 무관하게 본 발명의 범위에 속한다고 판단하여야 한다. 의심스러운 경우를 방지하게 위하여, 본 명세서에 기재된 모든 신규한 내용과 그 조합에 대한 권리의 보호를 구하는 바이다.

본 발명은 복수의 운영체제를 한 컴퓨터 내에서 운용하는 데에 있어서 시스템 자원을 절약하고, 통상적으로 시판되는 운영체제 프로그램에 제한적인 변화를 가하는 것만으로도 설치 가능하고 운영체제의 새 버전을 다중 운영체제 방식에서 작동하게끔 고치는 수고가 거의 들지 않는 컴퓨터의 다중 운영체제 운용 방식을 제공한다.

Claims

복수의 다른 운영체제 프로그램이 동시에 동일 컴퓨터에서 수행될 수 있도록 하는 방법으로서

상대적으로 높은 우선 순위를 가지는 제1운영체제를 선택하는 단계,

상대적으로 낮은 우선 순위를 가지는 제2운영체제를 적어도 하나 이상 선택하는 단계,

미리 정해진 조건 하에서 상기 운영체제들 사이를 교환하도록 정해진 공통 프로그램을 제공하는 단계,

상기 제1운영체제와 제2운영체제가 상기 공통 프로그램에 의하여 제어될 수 있도록 조절하는 단계를 포함하는 운영체제 운용 방법.
제1항의 운용 방법에 있어서, 상기 제1운영체제는 실시간 운영체제인 운영체제 운용 방법.
제1항의 운용 방법에 있어서, 상기 제2운영체제는 비실시간 범용 운영체제인 운영체제 운용 방법.
제1항의 운용 방법에 있어서, 상기 제2운영체제는 리눅스 또는 그 하나의 버전인 운영체제 운용 방법.
제1항의 운용 방법에 있어서, 상기 공통 프로그램은 상기 운영체제 사이를 교환하는데 필요한 관리장치의 상태를 저장하고 그 저장된 버전으로부터 복원하도록 정해진 운영체제 운용 방법.
제1항에 있어서, 상기 제2운영체제의 프로세서 예외는 상기 공통 프로그램이 가상 방식으로 관리하는 운영체제 운용 방법.
제1항에 있어서, 상기 공통 프로그램은 몇 가지의 프로세서 예외를 인터셉트하고 또한 그 예외 서비스를 제공하기 위하여 상기 제1운영체제의 예외 관리 루틴을 호출하도록 정하여진 운영체제 운용 방법.
제1항에 있어서, 상기 제2운영체제의 프로세서 예외는 가상 예외로 포스트되 는 운영체제 운용 방법.
제8항에 있어서, 상기 공통 프로그램은 미결(未決 pending)인 상기 가상 예외에 대응하는, 제2운영체제의 예외 관리 루틴을 호출하도록 정하여진 운영체제 운용 방법.
제1항에 있어서, 상기 운영체제들 각각이 독점적으로 작동할 수 있는 독립된 메모리 공간을 각각 제공하는 단계가 추가되는 운영체제 운용 방법.
제1항에 있어서, 상기 운영체제들 각각이 상기 컴퓨터에서 독점적으로 접근(access)할 수 있는 제1입력장치 또는 제1입출력장치를 각각 제공하는 단계가 추가되는 운영체제 운용 방법.
제11항에 있어서, 상기 운영체제들 각각이 상기 제1입력장치 또는 제1입출력장치를 접근할 때 원시 루틴(native routine)를 실질적 변화 없이 사용하는 운영체제 운용 방법.
제1항에 있어서, 상기 운영체제 각각이 접근을 공유하는 제2입력장치 또는 제2입출력장치를 제공하는 단계가 추가되는 운영체제 운용 방법.
제13항에 있어서, 모든 운영체제는 제1운영체제의 상기 루틴을 사용하여 상기 제2입력장치 또는 제2입출력장치를 접근하는 운영체제 운용 방법.
제1항에 있어서, 상기 제2운영체제를 상기 제1운영체제나 공통 프로그램의 인터럽트 없이 재시작하기 위한 재시작 루틴을 제공하는 단계가 추가되는 운영체제 운용 방법.
제15항에 있어서, 상기 공통 프로그램은 상기 제2운영체제의 작동을 제어하기 위한 트랩 호출 메커니즘과 제2운영체제의 상태 변화를 제1운영체제에 포스트하기 위한 이벤트 메커니즘 중 어느 하나 이상을 제공하는 운영체제 운용 방법.
제15항에 있어서, 상기 공통 프로그램은 상기 제2운영체제 커널(kernel)의 시스템 이미지의 사본을 저장하고 그러한 사본으로부터 상기 제2운영체제 커널을 복원하도록 마련된 운영체제 운용 방법.
제15항에 있어서,상기 제1운영체제는 제2운영체제가 계속하여 작동하는지를 감시할 수 있고, 제2운영체제의 시스템 장애(crash)를 감지할 수 있도록 제2운영체제와 서로 협력하는 루틴을 가지는 운영체제 운용 방법.
제1항에 있어서, 상기 공통 프로그램은 상기 운영체제들의 작동 중 미리 정해진 조건이 성취된 경우 컴퓨터 장치(machine)의 상태 변수를 출력하도록 마련된 디버그 루틴을 제공하는 단계가 추가된 운영체제 운용 방법.
제1항에 있어서, 상기 운영체제들과 공통 프로그램은 하나의 프로그램 코드로 통합된 구성으로 갖춘 운영체제 운용 방법.
제1항에 있어서, 상기 운영체제들과 공통 프로그램은 컴퓨터 장치의 영구 메 모리상에 임베딩(embedding)되는 구성이 추가된 운영체제 운용 방법.
제1항에 있어서, 상기 공통 프로그램은 상기 제1운영체제와 제2운영체제 사이의 통신이나 그 운영체제에서 수행되는 응용 프로그램(application)들 사이의 통신 중 적어도 하나 이상이 가능하도록 하는 운영체제간 통신 메커니즘을 제공하도록 마련된 운영체제 운용 방법.
제22항에 있어서, 상기 공통 프로그램은 통신 버스 브리지에 일치하는 가상 입력장치 또는 가상 입출력장치 중 적어도 하나를 규정하고 있어서, 상기 운영체제들이 마치 통신 버스에 의한 방식과 유사하게 통신할 수 있게끔 하는 운영체제 운용 방법.
제23항에 있어서, 상기 운영체제들을 조절하는 단계는 상기 가상 버스 장치들을 관리하는 드라이버 루틴을 추가하는 것을 포함하는 운영체제 운용 방법.
제1항의 단계들을 수행하기 위한 프로그램 코드로 이루어진 소프트웨어 개발 키트 컴퓨터 프로그램.
제20항에 의하여 상기 공통 프로그램과 운영체제를 통합한 컴퓨터 프로그램.
제24항의 방식에 따라 영구 메모리에 내장된 프로그램을 갖추고 CPU, 메모리 장치와 입출력 장치로 구성된 내장 컴퓨터 시스템.
CPU, 메모리 장치 및 입/출력장치를 포함하는 컴퓨터 시스템에 있어,

상대적으로 높은 우선 순위를 가지는 제1운영체제,

상대적으로 낮은 우선 순위를 가지는 제2운영체제,

미리 정해진 조건 하에서 상기 운영체제 사이를 교환함으로써 상기 운영체제들을 동시에 작동하도록 마련된 공통 프로그램을 포함하는 컴퓨터 프로그램 코드가 수행되는 컴퓨터 시스템.
제28항의 컴퓨터 시스템에 있어서, 청구항 1 내지 24의 운용 방법 중 어느 것에 의하더라도 상기 제1운영체제와 제2운영체제를 동시에 작동하도록 마련된 컴 퓨터 시스템.
제1항에 있어서, 상기 운영체제 각각에 상기 공통 프로그램으로 제어권을 넘기는 유휴(遊休 idle) 루틴을 제공하는 운영체제 운용 방법.
제30항에 있어서, 상기 유휴 루틴은 프로세서 정지 명령을 대체하는 운영체제 운용 방법.
제1항에 있어서, 운영체제 작동 도중 프로세서 예외가 발생하였을 때, 상기 공통 프로그램은

(a) 그 예외 서비스를 제공하기 위하여 제1운영체제의 예외 처리 루틴을 호출하고,

(b) 상기 예외가 미리 정해진 제2운영체제에 대하여 의도된 것이라면, 가상 예외를 만들며,

(c) 상기 예외에 대한 제1운영체제 서비스가 끝난 후에는 상기 공통프로그램이 상기 작동 중이던 운영체제를 작동하는 역할로 복귀하고

(d) 상기 공통 프로그램이 다음에 미리 정해진 제2운영체제로 교환할 때, 미 결 상태인 상기 가상 예외를 상기 예정된 제2운영체제에 고지하도록 마련되는 특징을 가지고,

상기 가상 예외에 일치하는 상기 예정된 제2운영체제의 예외 처리 루틴이 예외 서비스를 제공하기 위하여 호출되는 운영체제 운용 방법.
제1항에 있어서, 상기 제2운영체제는 인터럽트를 금지(masking)하지 못하도록 변경된 운영체제 운용 방법.
제1항에 있어서, 모든 하드웨어 인터럽트는 상기 제1운영체제가 우선적으로 처리하며, 제2운영체제들에 대한 인터럽트는 가상화되고 상기 공통 프로그램이 해당 제2운영체제에 할당될 때까지 보류된 뒤, 해당 제2운영체제가 인터럽트 서비스를 제공하는 운용 방법.
제8항에 있어서, 상기 공통 프로그램은 각 보조운영체제에서 가상 예외를 금지(masking)함으로써 상기 각 운영체제가 하드웨어 인터럽트 금지 코드(masking code)를 대체하는 수단을 제공하는 결과, 주 운영체제가 상기 보조운영체제를 완전하게 접수(pre-emptable)할 수 있게 되는 운영체제 운용 방법.
제9항에 있어서, 상기 제2 가상 예외는 금지되지 않는 운영체제 운용 방법.