[운영체제] Limited Direct Execution
Direct Execution
Direct Execution
Direct Execution 에서는 운영체제가 프로세스 리스트를 생성하고 프로그램에 대한 메모리를 할당합니다.
메모리로 프로그램을 load 한 다음 argc/argv 와 함께 스택 영역을 set up 하게 됩니다.
그 후 레지스터들을 초기화하고 main 함수를 호출하게 됩니다.
main 함수가 return 된 이후에 프로세스의 메모리를 Free 해준뒤 프로세스 리스트에서 삭제 시킵니다.
Direct Execution 의 문제점
하지만 Direct Execution 이 Limited 되어있지 않으면 응용 프로세스가 CPU 자원을 독점하기 때문에 운영체제가 응용 프로세스를 감시하지 못합니다. 운영체제 또한 일종의 프로세스이기 때문에 CPU 자원을 필요로 하고 그렇기 때문에 발생하는 문제입니다.
다시말해, 운영체제가 응용 프로세스의 Restricted operations 를 감시하고 Time sharing 을 할 수 있게끔 해줘야 합니다.
Problem #1 : Restricted Operations
- Issuing an I/O request to disk
- Gaining access to more system resources, such as CPU or memory -> 운영체제는 프로세스에 Restricted Opertations 를 허용해주되, 안전하게 사용할 수 있도록 방법을 제공해야 합니다. 그 방법으로 Processor Modes 와 System calls 등이 있습니다.
Processor Modes
CPU 가 여러가지 모드를 제공하고 각 모드에서 실행할 수 있는 권한을 다르게 설정해 놓은 것 입니다. 다시말해, 운영체제가 만든것이 아닌 CPU가 제공하는 Modes 입니다.
- User mode : Restricted operations 를 사용하려고 할 때, Exception 을 발생시킵니다.
- Kernel mode : Restricted operations 을 사용할 수 있습니다. 운영체제는 Kernel mode 에서 실행됩니다.
System calls
- Trap instruction : 커널 모드로 진입 시킵니다.
- Return-from-trap instruction : 커널모드에서 유저모드로 다시 복귀 시킵니다.
- 시스템 콜을 무차별적으로 사용하지 못하게 하기 위해 Trap Table 을 사용합니다.
- machine 이 부팅될 때 Trap table 은 초기화 됩니다
- Trap table 에는 소프트웨어적 사건들을 처리하기 위한 함수가 들어있습니다.
- system-call number 이라는 번호가 정의되어있습니다.
즉, 운영체제 내부의 특정 주소에 접근할 수 있는것이 아닌 미리 정해져있는 번호에만 restricted operation 을 요청할 수 있습니다.
Stacks in Limited Direct Execution
- user stack
- kernel stack
main() 함수가 불리고 user mode 일때 user stack 에는 argc/argv 정보를 포함한 다른 함수 등이 저장됩니다. System call 이 불려지고 trap instruction 이 발생하면 Kernel mode 로 들어가면서 user mode 에 실행하던 User 의 Context 정보를 Kernel Stack 에 저장시킵니다. 예를들어, CPU register 혹은 Program counter 값들이 저장됩니다. system call 을 실행하기 위한 stack frame 들이 쌓이고 실행이 종료되면 모든 frame 들이 pop 되고, 이후 return-from-trap 이 호출되면 user mode 로 바뀜과 동시에 CPU 의 context 정보를 restore 합니다.
- Loading
실행파일을 laod 할 때, kernel mode 에서 시작됩니다. user stack 에 입력받은 초기 User context 정보들을 인위적으로 kernel stack 에 저장합니다. 왜냐하면 main 함수를 호출하기 위해 return-from-trap 을 하는데, 이때, kernel stack 의 user context 정보를 동시에 가져오려 하기 때문입니다.
Problem #2 : Switching Between Processes - Time sharing
만약 한 프로세스가 CPU를 독점한다면 이것은 운영체제가 실행될 수 없다는 것을 의미합니다. 즉, 운영체제가 프로세스 간 time sharing 을 설정해주기 위해선 한 프로세스가 CPU 를 독점하게 해서는 안됩니다. 운영체제가 CPU를 다시 얻기 위해선 여러가지 방법이 있습니다.
wait for system calls
- 시스템 콜이 호출될 때마다 kernel mode 에서 운영체제가 CPU 자원을 얻게 됩니다, 이때 time sharing 을 해주는 방법이 있습니다.
- 시스템 콜 외에도 dividing by zero 혹은 segmentation fault 등 illegal operation 으로 인해 운영체제가 cpu 를 얻을 수 있습니다 이러한 방법은 프로세스의 시스템 콜을 줄여서 프로그램이 CPU 를 많이 사용하도록 할 수 있습니다. 그러므로 위의 방법은 좋은 방법이 아닙니다. 이것을 해결하기 위해 운영체제는 timer 라는 것을 사용합니다.
Timer Interrupt
Timer 는 주기적으로 interrupt 를 발생시키도록 프로그램되어 있습니다. interrupt 가 발생했을 때, 현재 running 중인 프로세스는 멈추고 운영체제가 다시 cpu 자원을 뺏게 됩니다. 운영체제는 이때 context switch 를 수행하게 됩니다.
Context Switch
- 현재 실행하고 있는 프로세스의 context 를 kernel stack 에 저장합니다.
- CPU 를 주고자 하는 프로세스의 context 정보를 환원합니다.
- context switch 가 진행된 후 return-from-trap 을 역시 사용합니다.
(예시)
프로세스 A -> Trap -> Kernel Stack 에 user context 저장 -> Timer Interrupt -> 프로세스 A 의 context 정보를 kernel stack 에 저장 ->
프로세스 B의 kernel context 정보를 restore -> CPU 의 Address space 를 switch to 프로세스 B -> switch k-stack -> return-from-trap ->
user context 정보 환원