User program and System Call

Kernel 

- Os 메모리에 항상 상주하는 핵심적인 영역

- 주로 c로 쓰여짐(절차지향적 언어에서 c가 효율이 좋음)

- Hardware적으로 운영되는 일부 부분은 어셈블리어로 제공되고, speed가 중요해짐

- 다양한 함수들의 집합(이 함수들이 무엇을 하냐?

      -> Process management, synchronization, cpu scheduling, memory management, device management, interrupt handling)

- System call(위 함수들 중 일부분을 user program이 사용할 수 있게 해줌)을 이용해 제공

 

Utility(Command)

-kernel을 제외한 모든 것(user program도 포함하는 개념)

- Disk에 상주

- 요청이 있을 때 memory에 올라감

 

 

Shell

- Special utility

- 유틸리티를 위한 유틸리티

- 유틸리티를 control함 (command control)

 

OS의 범주를 나눌 때 kernel만 볼 수도, shell까지 포함할 수도, 규정하기 나름이다.(논란이 있다.)

 

 

test.c에 소스코드를 작성하면 이 소스코드는 disk의 어딘가에 저장된다.

이 후 컴파일($gcc test.c)을 하면 결과인 a.out인 도출된다. 

디스크에 저장되는 a.out은 프로그램이다 (프로그램은 명령어와 코드의 집합)

shell은 while문을 돌면서 a.out을 입력하면 disk에서 a.out을 찾고 a.out은 메모리에 올라간다.

메모리에 올라오면 프로세스라고 한다. 프로세스는 실행중 혹은 실행가능한 프로세스이다.(code,text,stack영역 모두 프로세스)

프로세스를 관리하기 위한 metadata를 PCB라고 한다.

 

Dual-Mode

-  대표적인 두가지 모드가 kernel/user mode

- 현재 OS는 모드가 2개이상 지원됨

- 목적 : 하드웨어는 불법적 행동으로 부터 “prevent”하는 것을 도운다 (system resource 보호 위해)

- 하드웨어는 mode bit를 통해 최소 두가지 모드를 구분하는 것을 제공한다.

 

Kernel모드

• 모드 비트는 0
• 모든 opcode 실행가능
• 모든 곳에 접근가능
• 모든 레지스터 이용 가능

User 모드

• 모드 비트는 1
• 특권모드 접근 불가능
• user모드의 메모리만 접근가능
• special register 이용 불가능

kernel mode / user mode

 

Dual mode operation

- User은 I/O(disk, printer, etc)에 직접 접근 불가능(privileged instruction or memory mapping 통해서만 접근가능)

- I/O 관련은 모두 privileged operation

- memory management state(page table pointers, TLB load, etc)를 조작하는 명령어를 제어해야한다

     -> OS가 관리해야 할 정보들을 특권 operation으로 규정

- Setting of special mode bits(kernel mode) 등

     -> set 시키는건 privileged instruction

 

Instruction cycle 에서

• Decode 하는 중에 특권 모드의 opcode가 발견되면 중단 (exception 중 하나- illegal opcode)
• Execute에서 Memory로 넘어가는 중에 illegal address 발견되면 중단(exception)

 

Mode transition

Kernel 모드 비트 0, user 모드 비트 1이다.

    -> 모드 비트 설정은 주로 psw의 파트이다.

인터럽트, 트랩 발생 시 하드웨어는 kernel mode로 변환한다.

    -> 모드비트 바꾸는 명령어는 특권모드이다.

 

Kernel에서 user모드는 접근가능 하지만 반대는 불가능하기에

Interrupt, trap(exception), system call을 통해 접근가능

---

CPU protection

• cpu 독점문제 ( CPU는 계속 루프 돌기에 끼어들 틈이 없음 -> kernel이 개입하게끔)
• 보안이 아니라 보호(not security)
• 이를 위해 System timer 등장

System timer

• 특정 시간 뒤 인터럽트 발생 (PIT - 이 후에 설명 예정)
• E.g. kernel program 타이머는 100ms마다 인터럽트 발생시킴
• 타이머인터럽트 발생하면 OS(kernel)영역으로 진입한다.
• Timesharing systems에 사용되고, wall time(몇년 몇월....) 업데이트 하는데 사용됨
• 타이머는 privileged mode : OS만 load 할 수 있다.
• 어떠한 유저프로그램이 CPU를 점유하더라도 timer로 뺏어올 수 있다고 보장됨

 

 

Absolute time(절대시간)

- Benchmark(기준) 없음

- 유닉스 시스템은 절대시간을 1970년 1월 1일부터 경과된 시간의 수로 나타냄(“epoch”)

Relatie time(상대시간)

- Benchmark(기준) 있음

- 예를 들어 5 seconds( from now) 이렇게 ‘현재부터’라는 기준이 있음

 

System timer

- PIT(programmable Interval Timer)라고 불림

- 주기적으로 인터럽트 가져옴 -> hitting at HZ (tick)

- Extern unsigned long volatile jiffies;

- 여기서jiffies는 매 타이머 인터럽트마다 증가한다 == tick

- Date 명령어

 

PIT vs RTC

*PIT는 상대시간, RTC는 절대시간

 

Hz

- 초당 tick 개수 -> timer 인터럽트 핸들러(ISR)

- 대부분의 architecture에서 Hz는 100

Jiffies

- Tick 개수

- 전역변수 (SMP에서는 각 timer interrupt 중 하나만 올라감)

Jiffies-Hz conversion

- Relative time(sec) = jiffies/Hz

E.g_ unsigned long later = jiffies + 5 * HZ;

 

[Linux에서 타이머 인터럽트 핸들러 실행 과정]

1. Jiffies 업데이트

2. Xtime에 저장된 Wall time(절대시간) 업데이트

3. Process time 업데이트(자원관리가 다 여기서 이루어짐)

    3-1) 현재 실행되는 프로세스를 위해 resource usages 업데이트

    3-2) Time slice 업데이트(check for quantum expiration)

 

time out, system call 이 일어날 때 마다 kernel mode로 진입한다.

 

Context switch(process switch/ mode switch)

- Process switch : process 전환

- Mode switch : mode 전환

- Mode switch가 process switch 보다 훨씬 많은 이유는 process switch가 일어나려면 mode switch가 필연적이기 때문이다.

---

 

 

[Memory protection]

MMU(memory management unit)

- Logical memory address 에서 physical address로 변환을 지원

- Memory protection, cache control, bus arbitration을 동시에 다룸

- 메모리관리상태를 조작하는 명령어(page table pointers, TLB load, etc)

 

[I/O protection]

- 모든 I/O instructions은 privileged instructions

- User이 privileged 관련한 모든 것에 접근하려면 OS procedure을 call 해야한다.

- 어떻게? -> system call!!

 

 

Kernel Entry Point

- interrupt

- trap

- system call

(int 0x80 은 소프트웨어 적으로 interrupt 발생시키는 명령어)

System calls

- Programming interface to OS services

- Application이 OS와 communication하는 것을 허락

- Library와의 큰 차이는 interrupt 발생여부!!!!!!

 

[System call의 목적]

- 시스템 자원 보호(신뢰되는 OS와 그렇지 않은 것 구분해야 함)

- For reliability : buggy user program (무한루프, 메모리 많이 사용 등)

- For security : 악의적인 유저 프로그램 등으로부터 보호

 

 

 

 user program 입장에서 System call interface 진입하는 관문

-> Trap

 

 

 

잘 정의된 200개의 system call들이있음(compact) : 잘 압축해놓았다!

왜 작게 만들었냐?

- Highly portable : 사용자에게 보이는 부분이 작아서 Porting 할 부분이 줄어듦

- Robust : 방어를 위해 관문을 작게

 

system call 은 너무 일반화 되어 일반적이지 않은 상황에서는 상황이 어렵다.

사용이 어려워서 나온 잘 wrapping 한 함수 : library (API)

 

왜 system call보다 API(library)사용?

     1) OS 유연성

     2) 시스템콜 사용 어려움. 라이브러리가 이걸 쉽게 해줌

     3) printf는 결국 write를 콜함

     4) 각각의 os는 다른 시스템 콜을 가짐(POSIX API,Win32 API,JAVA API)

 

 

$ man read

read(s)

 

-> Read(2) 가 system call function

 

 

 

System call Implementation

User program

-       System call 함수를 호출 in library

-       유저 스택 레지스터에 인자 둔다(?)

-       Syscall number (3) 을 레지스터에 둔다

-       Syscall machine instruction을 수행

Kernel

-       Syscall interrupt handler 수행(인터럽트 핸들러가 아니라 시스템 콜 인터럽트 핸들러)

-       System call table(실제로 서비스하기 위해 mapping 된 테이블) 안에 sys_xxx() kernel function 수행

-       레지스터에 값 저장

-       RETURN_FROM_INTERRUPT 수행

system call 실행 과정

user process에서 read() 호출한다.

read()함수 들어가면 int$0x80 필연적이다.

그 전에!

mov 3,%eax ( read하겠다는 약속)이 실행되고,

인터럽트 발생한다.

인터럽트 비트 1로 바꾸고 인터럽트 핸들러로 점프

idt 테이블의 128번지 system_call이다.

system call 함수로 들어가자(이게 하드웨어적으로 들어가는 entry point이다.)

system call 함수를 쭉쭉 가다보면 아까 보았던 %eax가 또 보인다.

이전에 넣어주었던 값 3을 읽어온다

3번지로 가면 sys_read 함수를 만날 수 있다.

sys_read()함수에 들어가면 실제 실행되는 코드가 있다.

 

 

System Call Parameter Passing

1. 레지스터 (가장 기본적)

2. 블락(block)

- 더 커지면 메모리 사용하여 block에 저장. 블락의 시작주소, 크기 등을 둔다

- 리눅스나 solaris에서 사용하는 방식인듯

3. 스택(stack)

- 스택에서 푸쉬,팝 등

블락, 스택방식은 전달되는 파라미터의 수나 길이에 제한이 없다.

 

 

System call의 종류 (system library)

• Process
• Scheduling
• Interprocess communication
• File system
• Socket
• Miscellaneous