리눅스 커널 심층 분석 - 5장, 시스템 호출

커널과 통신 

• system call은 apps가 정상적으로 커널로 진입하는 유일한 방법임 
• 장치 파일이나 /proc도 system call을 통하게 되어 있음 

API, POSIX, C 라이브러리 

• POSIX: 유닉스 기반 운영체제 간의 이식성 제공을 목적으로 정해진 IEEE 표준의 집합 

syscall 

• getpid()와 같은 syscall은 다음과 같이 구현되어 있음 
• SYSCALL_DEFINE0(getpid) --> asmlinkage long sys_getpid(void) // 인자가 없는 syscall 선언임 { return task_tgid_vnr(current); //current의 tgid 반환. } 
• 일반적으로 sys_xxxx로 선언함. 
• 등록된 모든 syscall 목록을 sys_call_table에 저장함. 
• # strace <명령> --> system call trace 함. 

시스템 호출 핸들러 

• 사용자 공간의 apps는 직접 커널 코드를 호출할 수 없다 ㅋ 
  • 심지어 변수도 호출 할 수 없으므로 의 copy_from_user와 같은 함수를 사용한다. 
  • 커널에 신호를 보내는 방법은 SW interrupt를 이용함. 인터럽트 발생하면 kernel mode로 전환되어 커널 코드를 실행할 수 있다. 여기에 호출 번호까지 전달하면 알맞은 system call을 찾아서 동작한다. 
• architecture dependent하게 구현되어 있음. 
  
  

signal(시그날)에 대해서… 

• ^C는 HW interrupt가 아니라 interrupt signal임. 
• 이 외에도 ^\, ^s/^q, ^z 등이 있음. 이는 $ stty -a로 확인 가능함. 
• 리눅스의 모든 signal 보고 싶으면 $ kill -l 해볼 것 
  • ex. SIGCHLD는 child가 exit 하면 parent에게 보내는 signal임 
• 즉, signal은 kernel이 주는 signal을 말하는 것임 
• signal은 default 행동이 있는데 이를 process에서 변경할 수 있음. 
  • signal의 deault를 변경하는 것을 등록하는 함수는 signal() 
• signal의 우선순위: HW interrupt > signal > 일반 app 
• signal의 handler 동작 중에 같은 signal이 오면 무시, 다른 signal이 오면 동작함. 이는 에 있는 다른 함수들을 사용해서 조정할 수 있음. 
  • 예를 들어, kill -3 으로 죽이면 죽는데 kill 하면 안죽는다.. 이는 quit을 보낸 것인데 이는 내부적인 signal을 변경했을 것이다. 이는 kill -9로 하면 kill 할 수 있다. 9는 sigkill로 SIGIGN를 setting할 수 업음. 
• 시그널 처리 동작 
•