본문 바로가기
Operating System/Ch2) System call

System call

매효계니 2024. 10. 27. 20:36

Mode switch : User → Kernel

  • 그렇다면, Ch1에서 본 Memory protection에서 user에서 kernel모드로는 어떻게 전환될까?
  • 다음과 같은 3가지 방법이 존재한다.
  • Interrupts
    • 미리 저장한 kernel의 code이다.
    • Externel hardware에 의해서 Trigger된다(ex timer and I/O)
  • Exceptions(=traps)
    • 주로 software의 unexpected program behavior or malicious behavior에 의해 Trgger된다
  • System calls
    • exception mechanism에 의해서 구현된다 ( exception 발생하면 이를 해결하기 위해 syscall 호출)
    • process에 의해 requested되며, process를 대신해 kernel에서 어떤 동작을 수행한다

Mode switch : Kernal → User

  • New process/thread가 시작될 떄
    • program이나 thread의 첫 번째 instruction으로 Jump한다
  • interrupt, exception, syscall로부터 Return 할 때
    • 중단되었던 execution을 재개한다
  • Process의 Context switch가 일어날 때
    • 다른 process를 재개한다
  • User-level upcall이 발생할 때
    • Asynchronous notifican을 프로그램에 알려준다.

Data Transfer Modes

I/O design question

  • 그렇다면, 어떻게 I/O를 효과적으로 구현할까?

 

 

  • I/O devices와 Cpu는 동시에 execute할 수 있다.
  • 특정 device type마다 담당하는 device controller가 존재한다
  • 각각의 device는 local buffer을 보유한다
  • CPU는 I/O명령어로 I/O devices에 전달한다
  • CPU는 main memory와 I/O device의 local buffer 사이에서 data를 운반한다.
  • CPU는 time-consumin tasks로부터 자유로워야 하기에
    • 운송 시간이 짧은 main memory와 local buffer 사이에서 data를 운반하고
    • Device가 명령한 명령어를 수행했는지 안했는지 주기적으로 확인한다.

Data transfer modes

  1. Programmed IO ( PIO )
  • CPU가 직접 memory와 I/O devces 사이의 data를 운반하는 것에 관여하는 방식(직접 data 교환)
  •  

 

 

2.  Direct Memory Access( DMA )

  • 주로 대역폭이 높고 빠른 데이터송이 요구되는 장치가 사용
  • CPU의 관섭 없이 DMA라 Divice controller가 main memory에서 local buffer 사이의 data 전송 알아서 시행
  • Data 전송이 block 단위로 이루어지고, block 단위에서만 interrupt가 발생
  •  

 

 

→ 그렇다면, CPU에게 Date transfer이 마무리되었다는 건 어떻게 알림?

Event Notification to CPU ( or kernel )

  • Polling
    • 정해진 시간 간격의 특정 하드웨어의 장치 상태를 확인 → 특정 조건이 만족되었으면 시스템은 적절 응답 수행
    • CPU 바빠죽겠는데 I/O까지 확인할 시간 어딨음?;;;;; 그래서 나온
  • Interrupt
    • device가 I/O수행을 완료했다는 것을 CPU에 알리기 위해 발생
    • Hardware-based mechanism임
      • CPU는 각각 interrupt pin이라고 하는 물리적핀 보유
      • Pin에 가는 signal이 interrupt handling 발생시킴
    • 이렇게 함으로써 CPU는 I/O에 신경쓸 시간에 다른 동작 수행 가능
    •  

 

 

그렇다면, 이러한 interrupt를 어떻게 Handling하는가?

Handling interrupts ( or exceptions )

 

 

  • Interrupt가 들어오면, 실행중이었던 user process의 context를 저장해놓는다
    • 여기서 Context란 CPU register값들임 (IP, SP 등등)
    • interrupt stack(fixed location)이라는 스택에 저장함
  • 이후 interrupt handler에게 control을 넘긴다 ( Interrupt Service Routine)
    • 참고로 kernel은 boot time때 ISR들을 set up 해놓음

→그럼, Interrupt stack이란 무엇인가

Interrupt stack

  • Core마다 kernel memory에 갖고있는 stack임.
  • 보통 process/thread는 kerenel stack와 user stack을 모두 보유하고 있음.
  • Interrupt stack은 kernel stack의 한 부분이다!

 

 

→ 그렇다면, Interrupt handling을 하는 도중 interupt가 들어오면 어떡해?

  • interrupt stack < kernel stack < kernel memory < virtual memory (각 용어별 범위: 참고바람)

Interrupt Masking

  • Interrupt handler는 interupts가 off된 상태로 동작한다 !
    • interrupt 비활성화 ⇒ interrupt 처리 ⇒ interrupt 재활성화
    • x86에서는 CLI: disable interrupts / STI : enable interrupts 명령어임

→ 그렇다면, Interrupt handling이 완료된 후 Return은 어떻게 이루어지는가?

Returning from interrupt

  • 일단, Kernel이 적절한 Interrupt handling을 진행함
  • 이후, Control을 interrupt handler에서 interrupt를 당한 user process로 넘겨주게 된다.
    • 이 때, interrupt handling을 시작하기 전 보관해놓았던 context를 interrupt stack으로부터 복원하는 과정을 포함함.
    • IP, SP와 같은 Context를 복원한다는 것은,CPU가 interrupted된 user code를 다시 실행하게 해주는 것과 같다
    • 근데 X86에서는 바로 kernel에서 user-level로 넘어가진 않고 iret 명령어 사용해야함

티스토리툴바