OS	프로그램
프로세스 리스트에 프로세스의 엔트리 등록 (Ready Queue)
실행하기 위해 프로그램을 위한 VM 할당(실행을 하기 위한 최소 사이즈만 할당)
스토리지에 있는 프로그램을 메모리로 (CPU는 스토리지에서 다이렉트로 실행할 수 없다.)
스택 셋업 (argc/argv)
레지스터 초기화
main() 함수 콜 실행
	main() 실행
	main()으로부터 return 실행
프로세스의 메모리 삭제
프로세스 리스트에서 삭제

프로그램이 돌면서 여러가지 일이 발생할 텐데 도는 시점에서 OS가 감시, 관리하지 않아도 괜찮나?

아니. 안괜찮다. 두가지 문제가 있다.

OS가 우리가 원하지 않는 행동을 하지 않는다고 어떻게 확신할 수 있는가?

OS가 프로세스를 중단시키고 다른 프로세스로 어떻게 전환시킬것인가?

OS	프로그램
main() 함수 콜 실행
	main() 실행
(정책)
제한된 Operation을 실행하는가?
점유율 제한 및 Time sharing
	main()으로부터 return 실행

다음과 같이 OS가 프로그램을 감시해야한다. 어떻게 할 수 있을까?

•

프로그램 카운터가 증가하면서 인스트럭션이 실시간으로 감시당하는 방법

◦

너무 느려진다.

Problem #1 : Restricted Operations(a.k.a. Previleged Operations)

OS는 모든 권한을 갖고있다. 즉 최고레벨의 권한을 가지고 있는데,

유저 레벨에서는 권한이 과하면 문제가 생길 수 있다.

제한된 Operations

•

I/O 리퀘스트

•

시스템 자원에 엑세스를 얻는 것

어플리케이션은 제한된 범위내에서 기능을 수행해야함.

Processor Modes

기능들에 따라서 유저가 실행할 수 있는 것과 커널이 실행할 수 있는 것으로 나눠놨음.

•

User mode

◦

유저 모드로 돌아가는 코드는 할 수 있는 일이 제한되어 있음.

◦

Restricted operations는 프로세서가(하드웨어 레벨에서) 예외상황을 도출하는 결과를 만들 수 있다.

•

Kernel mode

◦

모든 권한을 얻음

◦

OS는 커널모드

System Calls

OS 안에서는 커널모드로 동작하도록 하고, OS 밖에서는 유저모드로 동작하도록 함.

•

유저모드에서 커널 레벨 급의 Operation이 필요할 때 시스템 콜을 부르면 된다. 

시스템 콜의 중요부분은 다 운영체제 안에서 구현되고 있다.

→ 이게 어떻게 호출이 되지?

•

유저 라이브러리에 들어감

•

커널 함수를 호출

◦

안됨! → Previleged Operation이기 때문에 유저레벨에서 커널 함수를 부르면 에러가 뜬다.

◦

이를 위해서 Trap 인스트럭션을 부른다.

▪

운영체제 안으로 들어감.

◦

Trap을 통해서 안에 들어가서 OS 단계의 인스트럭션을 수행한 이후, return-from-trap을 통해 권한 레벨을 다시 낮춘다.

Trap Table

trap 인스트럭션이 들어갈 수 있는 함수의 어드레스 스페이스 테이블

•

Trap 테이블의 인덱스값만 명시할 수 있다.

→ OS가 들어와도 되는 입구만 정리해놓은 배열!!

시스템 콜을 호출할 때 여러 조건을 모두 검사하고(인자 체크 등등) 나서 안전할 경우 들어가는 방식

Limited Direct Execution Protocol

	OS	하드웨어	프로그램
부트	트랩 테이블 실행	시스템콜 핸들러(트랩테이블)의 주소 저장
런타임	PCB제작
	프로그램 메모리 할당
	프로그램 로드 → 메모리
	유저스택 설정
	커널 스택 설정
	return-from-trap(랭크다운)
		커널스택으로부터 레지스터 복구
		유저모드 전환
		메인으로 전환
			메인()
			시스템콜
			Trap to OS
		커널스택으로 regs/PC 저장
		커널모드로 전환
		트랩 핸들러로 점프
	트랩 핸들
	return-from-trap(랭크다운)
		커널스택으로부터 레지스터 복구
		유저모드 전환
		메인으로 전환
			return from main()
			Trap(via exit())
	프로세스의 메모리 초기화
	프로세스 리스트에서 제

시스템 콜 호출 → Trap → 트랩 핸들러 → Return-from-trap

•

커널 안으로 진입하는 것도 일종의 컨텍스트 스위치

◦

그러나 프로세스가 교체되지 않았기 때문에 일반적인 프로세스 to 프로세스 컨텍스트 스위치는 아님.

◦

시스템 콜로 커널 안에 들어와서 실행하고 있음.

Problem #2: Switching Between Processes

어떻게 CPU의 컨트롤을 다시 얻는가?

Cooperative Approach

Time sharing을 하려면 운영체제가 CPU를 점유해야한다.(OS도 결국 코드 덩어리임)

exe가 시스템 콜을 불러주면 시스템 콜을 불러주면, OS가 권한을 잡으면서 밀려있던 일을 처리한다. 그 중 하나가 스케쥴링.

에러를 기다리다 에러가 발생했을 때, OS 안의 Exception Handler가 에러를 부르기 직전에 밀린 일을 처리한다.

Non-Cooperative Approach

Timer interrupt

•

타이머를 갖고 있는데(Monotonic?), 시간간격 후 마다 OS가 자원 재배분에 대한 권한을 행사한다.

◦

interrupt 간격이 짧으면 속도가 느려지고, interrupt 간격이 길면 한 프로세스가 독점하는 상황도 있음.

◦

Dynamic 하게 interrupt를 하는 방식으로 트렌드가 진화하고 있음. → NonDynamic은 4ms가 표준

Context Switch

커널 스택에 컨텍스트 정보를 저장하고 리스토어하는 과정이 필요하다.

Limited Direct Execution Protocol

Next chapter

04 : CPU Scheduling