05. System Calls

1. System Call (syscall)

; application이 h/w를 사용할 수 있도록 kernel이 추상화시켜 제공하는 interface 

(for. user application이 kernel에 진입하기 위한 유일한 수단, because task는 kernel mode에 있어야만 h/w를 사용할 수 있기 때문에)

cf) 다음 장의 interrupt, exception과 비교하기 (kernel code를 수행하는 context관점에서)

- 추상화된 h/w interface제공

- system 보안, 안정성 제공 (제공된 interface내에서 kernel resource 활용)

- virtualized system 환경 제공

* API (Application Programming Interface)

; application은 보통 syscall을 직접 사용 x, API를 이용해 접근함.

2. System Call Handler

; syscall number에 맞는 syscall을 찾아 호출

- exception이 발생하면 exception handler가 실행 (이 때 syscall을 호출하는 경우 exception handler를 syscall handler로 봄)

- (in x86) syscall을 통한 kernel로의 진입 방법

-int $0x80 (128번 interrupt가 system call exception)

-최근 sysenter (더 빠름)

*sysenter가 더 빠른 이유

-int 0x80은 context_switch에 필요한 모든 값을 백업/복구

-sysenter는 필요한 소수의 register만 백업/복구 

-parameter passing

-syscall number : %eax를 통해 전달

-parameters : register에 저장, 6개 이상일 시 모든 parameter가 저장된 user space address를 가리키는 pointer를 register에 저장

*asmlinkage 선언시 

해당 함수의 parameter를 stack에서만 찾을 수 있게 register가 아닌 stack에 참조하도록 compile함

*asmlinkage 사용이유 

register에 저장하는 방식이 빠르나, 직접 작성한 assembly code를 실행 할 경우 문제가 있을 수 있기 때문에 stack에 저장

-return value :  %eax를 통해 전달

* register 로 user space address 전달 하기 때문에 kernel에서 user space address로 access할 수 있음.

3. Process Context

; user application의 system call request으로 user application '대신에' kernel code를 수행하고 있는 상태 

- current()시 syscall 호출한 task 반환

- process context 에서 가능한 상태는 다음과 같음 

-sleeping

-syscall이 kernel에 대다수의 기능을 사용할 수 있음

-cf. interrupt handler

-실행중에 sleep상태가 될 수 있는 함수들은 interrupt context에서 사용 불가

-preemptible

-다른 task에 의해 preemption될 수 있음

-재진입이 가능해야함

-preemption 후 next process가 prev process와 같은 system call 실행할 수 있음