1. μ-Kernel, Interrupt handling

1. Operating system 이란?

일반적으로 application들을 위해 abstraction을 제공하는 system을 일컫음.

하드웨어의 상세는 low-level 인터페이스를 통해 접근하도록 하여 외부에 숨김

그 외 명칭

• Resource allocator (모든 리소스들을 관리)
• Control program (프로그램들이 에러없이 효율적으로 동작하기 위해 통제), 
• Kernel

2. Interrupt Handling

I/O 장치들과 CPU는 동시에 수행 가능하다 

• device controller 에 local buffer가 존재하여 main memory 와 controller buffer 사이에 데이터를 주고 받는다
• device controller 는 자신의 작업이 끝났다는 것(데이터를 받을 준비가 완료)을 interrupt를 통해 CPU에 전달한다.

IRQ 종류

• Non-maskable : 급한 interrupt 용
• Maskable
  
  

   * PIC (Porgrammable Interrupt Controller) : IRQ를 interrupt number로 변형시켜 CPU에 전달

Interrupt 처리 순서

1. CPU는 IRQ(Interrupt-request line)을 통해 매 instruction 실행 후 interrupt를 확인한다.

2. I/O device controller가 interrupt를 line에 sinal을 통해 전달한다.

3. CPU는 interrupt를 받고 난 후, interrupt handler에 전달한다.

a. Interrupt number를 확인

b. 메모리에 있는 IDT(Interrupt Descriptor table)에서 ISR(Interrupt Service Routine)을 찾는다.

4. Handler는 device에 service 함으로써 interrupt를 처리한다. (ISR을 실행한다.)

Nested Interrupt

같은 IRQ를 쓰고 있는 I/O 디바이스 중 이미 한 디바이스가 IRQ를 통해 interrupt를 요청한 상황에서 다른 interrupt가 요청 된 경우

  - 같은 IRQ를 쓰고 있는 경우는 IRQ의 order를 지키기 위해 다른 interrupt를 disable 시킨다. (chain을 사용하여 순서 지킴)
  - Top half(hf) 와 bottom half(bh) 로 분리하여 처리 (Interrupt의 지연시간을 줄이기 위해)

    a. Top half : request_irt()를 통해 등록되는 Interrutp handler
        디바이스 데이터를 device-specific buffer로 복사
        bh handler를 스케줄링

    b. Bottom half : Top half가 다 실행되고 난 이후 실행 되도록 top half에 의해 스케줄되는 Interrupt handler 
        bh가 실행되는 도중에는 모든 interrupt가 실행 가능하다
        프로세스 invoke
        도착한 데이터 전송
        다음 I/O 작업 시작

Livelock : 너무 많은 interrupt 요청으로 인해 user program 수행이 지연되는 현상 
   - 해결 ~ ksoftirqd 를 이용하여 CPU time을 공평하게 공유

Monolithic kernel VS. Micro kernel 에 대해서는 http://proneer.tistory.com/281 여기에서 자세히 설명되어 있음

3. 참고 논문

Exokernel : an operation system architecture for application-level resource management, SOSP(1995)

1. Motivation

기존의 Monolithic 커널에서 제공되던 high-level abstraction으로 인해 다음과 같은 문제가 발생
  - 일반적인 목적으로 만들어진 interface이기 때문에 각 application 은 performance 및 functionality 에 한계 존재
    (새로운 기능을 추가하려면 Kernel compile을 새로 해야 한다)
  - Hardware에 대한 정보를 알 수 없다 (eg. page fault)

2. Objective

최소한의 기능만을 갖는 커널 구현
  - 기존에 커널에서 관리하던 F/S 이나 Network management는 User-level에서 제공
  - 리소스 관리시 보호될 영역만 따로 분리하여 커널에서 관리 (다른 것은 User-level에서)

3. Design Principle

a. 추상화를 Kernel(Monolithic)이나, Server(Microkernel)에서 제공하지 않고, 라이브러리를 통해 제공 (libOS)

• 각 application의 특성에 맞도록 구현 가능
• 커널 crossing 횟수가 떨어짐 (커널에서 해야할 일들을 user-level에서 하기 때문)
• 라이브러리와 커널에 메타데이터를 주고 받으면서 라이브러리간의 통신과 공유 자원 충돌 현상 해결
  
  

b. 하드웨어들을 추가적인 정보 없이 보호하기위해 하드웨어, allocation 정보, name, revocation 정보를 application에 노출

• Secure binding (binding time에만 보호)
  
  

• Visible resource revocation : 리소스의 ownership을 trace 가능하도록
• Abort protocol : 강제로 resource deallocation
   
   ☞ Dynamic linking과 공유 라이브러리 시스템이 꼭 필요
  

4. Problems

라이브러리를 만드는 개발자 입장에서의 부담은 커진다 (라이브러리로 인해 성능 향상이 좌우되기 때문)

On μ-Kernel Construction, SOSP(1995)

1. Motivation

μ-kernel이 장점이 많음에도 불구하고 널리 사용되지 않고 있다.

• 시스템 구조를 쉽게 모듈화
• 임의의 application에서 발생한 오류로부터 다른 프로그램들을 보호
• User-level에서 application의 목적에 따라 원하는 기능을 선택 지원
  

2. Objective

μ-kernel의 성능 저하에 대해 원인 분석을 하여  μ-kernel이 비효율적이라는 주장이 틀렸음을 확인

3.  μ-kernel 구성 요소

a. Address spacing

• Grant : 임의의 주소공간의 owner가 다른 주소공간에 자신의 page를 할당, 할당되고 나면 기존 page는 삭제됨
• Map : 임의의 주소공간의 owner가 다른 주소공간에 자신의 page를 연결, 연결되고 나서도 기존 page는 보존
• Flush : 주소공간의 owner가 자신의 페이지를 flush
  

b. Inter-process Communication (IPC)

c. Thread management

d. Unique identifiers

4. Problem

이식성(Portability)이 낮다

• 실험결과에 대한 추론이 비약적인 부분 존재