Advanced Operating Systems Structure(2): SPIN

개요

지난 포스트에서는 Monolithic 구조와 u-kernel 구조에 대해서 알아봤다. 이번 포스트에서는 자원 보호나 성능을 희생하지 않고, 확장성 있는 OS 구조를 위한 방법에 대해서 알아보자. 그렇기 위해서 아래와 같은 조건을 충족시키는 문제 해결 방법에 대해서 알아보자

• Core Service는 정책 없이 메커니즘만 포함해야 한다.
• border crossing 비용 없이 자원에 접근할 수 있어야 한다.
• 보호나 성능의 희생 없이 자원을 유연하게 관리할 수 있어야 한다.

SPIN OS

SPIN Structure

먼저 워싱턴 대학에서 개발한 SPIN OS이 문제를 해결하기 위한 접근법을 알아보자. SPIN OS는 커널과 OS Service들을 같은 Protection Domain에 둠으로서 border crossing 문제를 해결한다. monolithic 구조와 같다고 볼 수도 있지만 다른 점은 각 OS Extension Service들이 모듈화 되어있다는 것이다. 그래서 필요한 모듈만 포함해서 OS를 구성한다.

이러면 보안적으로 문제가 있지 않냐고 생각할 수 있지만 강 타입 언어(SPIN에서는 Modula-3)를 사용해서 해결했다. C를 사용했을 경우는 pointer casting 등으로 제공하지 않은 인터페이스를 통해서 접근할 수 있지만 강 타입 언어에서는 불가능하다. 

또한 OS Extension Service들이 HW address space를 가지지 않는다. Logical Protection Domain을 가지고 메모리 접근을 한다. Moula-3의 특성을 이용해서 Logical Protection Domain을 구현했다.

OS Extension Service Interface는 미리 제공되어있기 때문에 동적으로 Call Binding 할 수 있다. 마치 OS Service를 일반 함수 콜처럼 사용할 수도 있다. 이 말은 유연성(Flexibility)이 좋다는 의미이다.

Logical Protection Domain

Logical Protection Domain 구현 메커니즘을 알아보자.

Modula-3

• strong typed language: 강 타입 언어는 다른 타입으로 캐스팅을 허용하지 않기 때문에 잘못된 방법으로 OS Extension Service에 접근하는 것이 불가능하다.
• autu memory menagement: 자동으로 메모리 관리를 해주기 때문에 allocation/free 문제도 해결된다.
• generic interface: 제네릭 인터페이스를 지원함으로 유연성도 보장된다.
• objects, threads, exception 등도 제공된다.

OS 기능을 통한 Fine-grained protection 

특정 OS Extension Service들을 구현한 오브젝트들은 시스템 설계자에 의해서 특정 단위로 관리될 수 있다. Memory Management를 예시로 어떻게 관리되는지 알아보자.

• hardware resources: 독립적인 하드웨어 자원을 오브젝트들로 관리할 수 있다. 예를 들어 page frame
• interfaces: 오브젝트에 대해서 특정 기능을 제공하는 인터페이스. 예를 들어 page allocation
• collection of interfaces: 오브젝트들을 다루는 전체 서브시스템. 예를 들어 전체적인 Virtual Memory Management System.

포인터로 다뤄지는 OS 기능들의 오브젝트

전통적으로 OS 오브젝트들을 다루는 방법은 무거운 메커니즘을 가진다. 그러나 SPIN OS에서는 강 타입 언어를 가지고 OS 기능들의 오브젝트를 pointer로 다루기 때문에 리소스에 접근할 때 비용이 적게 든다.

Protection Domain을 위한 SPIN의 메커니즘

SPIN OS는 Protection Domain을 만들기 위한 3가지 메커니즘(Create, Resolve, Combine)을 가진다.

• Create: 오브젝트 파일들을 초기화하고, 오브젝트 파일 내에 entry point가 될 수 있는 함수들을 만들고, name을 export 한다.
• Resolve(link): 마치 2개의 compile 된 파일을 link 하는 과정과 비슷하다. export 된 name들을 가지고 동적으로 하나의 protection domain에서 다른 protection domain의 resolve 하게 되면 동적으로 link 되고 같은 바운더리를 같게 된다. 한번 resolve 된 자원은 접근 시 memory speed로 접근 가능하다. 마치 함수 호출처럼 사용할 수 있다는 의미이다.
• Combine: resolve 된 domain들 간에는 aggregate domain을 형성할 수 있다. combine 된 domain들의 entry point의 집합이라고 할 수 있다. 

이벤트 메커니즘

SPIN은 이벤트 기반의 메커니즘을 가지고 있다. 각 이벤트 핸들러는 OS Service들이 등록할 수 있고, 외부 이벤트와 맵핑(1:N, N:1)되어있다. 위 그림의 오른쪽 그림을 보면 네트워크 패킷 이벤트 처리에 대한 플로우를 보여주고 있다. 동그라미는 이벤트, 사각형은 핸들러이다. L2, L3, L4 단계로 레이어 된 처리 과정을 볼 수 있다.

Core Service

OS는 memory management, CPU scheduling, threads, file system, network protocol stack 등 여러 가지 Service들을 제공해야 된다. 이중 memory management와 CPU scheduling은 모든 OS가 제공해야 되는 Core Service이다. 그러나 어떻게 구현해야 되는지는 정해진 게 없다. 이번에는 실제 동작하는 방법은 여러 가지 일 수 있으니 메커니즘인 인터페이스만 알아본다.

Memory Management

• Phsical address: allocate, deallocate, reclaim
• Virtual address: allocate, deallocate
• Traslation: create/destroy address space, add/remove mapping
• Event handler: page fault, access fault, bad address

CPU Scheduling

• SPIN abstraction: strand(scheduling 단위), strand의 의미는 Service에 의해 정해짐
• Event handlers: block, unblok, checkpoint, resume
• SPIN global scheduler: 전체 애플리케이션 thread들의 관리

정리

Core Service는 하드웨어를 제어하는 메커니즘을 가지고 있다. 그리고 그런 메커니즘을 어떻게 동작시키는지는 Extension들에 의해서 결정된다. 애플리케이션은 Core Service에 직접 접근하지 않고, Extension을 통해서 접근하게 하면서 Core Service에 영향이 가지 못하게 한다.