일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- BAM
- Friendship
- 삼성전자 소프트웨어멤버십 SSM
- 신경회로망
- Neural Network
- Bidirectional Associative Memory
- 갤럭시탭S8울트라
- 삼성
- 빅데이터
- 가상화
- Google App Engine
- 하이퍼바이저
- NarwalFreo
- hopfield network
- 동아리
- 멤버십
- 구글 앱 엔진
- 파이썬
- 나르왈프레오
- 고려대학교
- 물걸레로봇청소기추천
- 패턴인식
- 패턴 인식
- 증강현실
- 인공지능
- 물걸레자동세척로봇청소기
- Python
- 삼성소프트웨어멤버십
- SSM
- 신경망
- Today
- Total
정보공간_1
[6기 강북 전영진] 리눅스 커널 심층 분석 #3 본문
#Intro
안녕하세요. 강북멤버십 23-2기 전영진입니다.
이번엔 리눅스 시스템 호출에 대해 소개하겠습니다.
#커널과 통신
시스템 호출은 하드웨어와 사용자 공간 프로세스 사이에 있는 계층입니다.
- 시스템 호출의 역할
1) 사용자 공간에 하드웨어 인터페이스를 추상화된 형태로 제공.
2) 시스템 보안 및 안정성을 제공.
3) 사용자 공간과 기타 시스템 사이에 계층을 둠으로써 프로세스 별 가상 시스템 환경을 제공.
리눅스의 시스템 호출은 사용자 공간에서 커널과 상호작용할 수 있는 유일한 수단입니다. 장치 파일이나 /proc 파일시스템을 이용하는 다른 인터페이스도 결국은 시스템 호출을 통합니다.
#API, POSIX, C Library
어플리케이션은 일반적으로 시스템 호출을 직접 사용하지 않고, 사용자 공간에 구현된 어플리케이션 프로그램인 인터페이스 즉 API를 이용합니다. 어플리케이션이 사용하는 인터페이스 사이에 직접적인 연결이 없기 때문에 시스템에 따라 내부 구현이 전혀 달라도 같은 형태의 API를 사용함으로써 어플리케이션에 동일한 인터페이스를 제공 할 수 있습니다.
- Printf()호출 시 어플리케이션, C Library, 커널 사이의 관계
#시스콜
시스템호출(Syscall)은 보통 C라이브러리에 정의된 함수를 호출하는 방식으로 사용합니다.
시스템 호출은 성공과 실패에 대한 정보를 Long형의 값으로 반환합니다.
시스템 호출에서 오류가 발생할 경우 C라이브러리는 전역변수인 errno에 특정 오륙코드를 기록합니다. 라이브러리 함수인 perror()를 사용하면 이 변수의 값을 사람이 보기 편한 문자열 형태로 바꿀 수 있습니다.
SYSCALL_DEFINE0(getpid)
{
Return task_tgid_vnr(current); // current->tgid 값을 반환한다.
}
다음은 getpid()함수의 시스템 호출을 정의하는 매크로입니다. 이 매크로는 실제로는
asmlinkage long sys_getpid(void) 이와 같이 확장됩니다.
시스템콜 정의하는 방법:
1) 함수 정의 부분에 asmlinkage 지시자를 이용.
2) 함수의 반환값은 long형.
3) getpid() 시스템 호출을 예로 들면 커널 내부에서는 sys_getpid()라는 이름으로 정의
(모든 시스템 호출이 사용하는 명명 규칙 : 함수명 -> sys_함수명)
#시스템 호출 번호
리눅스의 모든 시스템 호출에는 시스콜 번호가 할당됩니다.
이 번호는 특정 시스템 호출을 참조하는 데 사용하는 고유번호입니다. 사용자 공간 프로세스가 시스템 호출을 실행할 때 스시콜 번호를 통해 실행할 시스템 호출을 알아냅니다.
시스콜 번호는 한번 할당하면 변경할 수 없으며, 이미 제거된 호출일 지라도 시스템 호출 번호를 재사용하지 않습니다. 그래서 리눅스에서는 ‘구현되지 않은’ 시스템 호출을 뜻하는 sys_ni_syscall() 함수를 제공합니다. 어쩌다가 시스콜이 제거되었거나 여타 이유로 시스템 호출을 사용할 수 없는 상황이 발생했을 때 이 함수를 이용해 ‘공백 메우기’를 할 수 있습니다.
커널은 등록된 모든 시스템 호출 목록을 sys_call_table이라는 시스템 호출 테이블에 저장합니다. 이 테이블은 아키텍쳐 별로 따로 존재하며, x86-64의경우 에는 arch/i386/kernel/syscal_64.c 파일에 저장됩니다. 이 테이블에는 유효한 시스콜마다 고유한 시스콜 번호가 할당 됩니다.
#시스템 호출 핸들러
사용자 공간 어플리케이션은 시스템 보안이나 안정성을 유지하기 위해 직접 커널 코드를 호출할 수 없습니다. 대신 사용자 공간 어플리케이션은 실행하고 싶은 시스템 호출을 커널에 알려서 시스템을 커널 모드로 전환하여 커널이 대신해 커널 공간에서 시스템 호출을 할 수 있습니다.
커널에 신호를 보내는 방법으로 소프트웨어 인터럽트라는 방법이 사용됩니다.
Exception이 발생하면 시스템은 커널 모드로 전환되고 exception handler가 실행됩니다. 소프트웨어 인터럽트의 경우 시스템 호출 핸들러가 exception handler가 됩니다.
X86에서 사용하는 소프트웨어 인터럽트는 int $0x80 명령을 통해 발생시키는 128번 인터럽트로, 이 인터럽트가 발생하면 커널 모드로 전환되고 시스템 호출 핸들러인 exception vercter 128번을 실행하게 됩니다.
#시스템 호출 구현
리눅스 시스템 호출의 실제 구현 작업은 시스템 호출 핸들러의 동작과는 별로 관련이 없습니다.
시스템 호출을 구현하는 첫 단계는 목적을 정의하는 것입니다.
리눅스는 복잡한 시스콜 사용을 권장하지 않습니다. 가능한 적은 개수의 인자를 사용하는 깔끔하고 간단한 인터페이스를 추구합니다. 또한 시스템 호출은 커널 공간에서 실행 됨으로 사용자가 잘못된 입력값을 커널로 전달함에 따라 시스템 보안과 안정성이 떨어질 수 있으므로 시스템 호출에서 사용되는 모든 매개변수가 유효하고 적당한지 주의 깊게 확인해야 됩니다.
#시스템 호출 등록 절차
1. 시스템 호출 테이블의 마지막에 항목을 추가.
2. 지원하는 모든 아키텍처의 시스콜 번호를 <asm/unistd.h>파일에 정의.
3. 시스콜을 커널 이미지로 컴파일.
#시스템 호출 추가의 장단점 및 대안
새로운 인터페이스의 시스콜 구현의 장점
- 시스템 호출은 구현이 간단하고 사용하기 쉽다.
- 리눅스의 시스템 호출 성능이 빠르다.
새로운 인터페이스의 시스콜 구현의 단점
- 공식적으로 할당된 시스콜 번호가 필요하다.
- 안정 버전 커널에 시스템 호출이 추가되면 유연성이 없어진다.
(사용자 프로그램에 영향을 주지않고 인터페이스를 수정할 방법이 없다.)
- 아키텍처 별로 시스템 호출을 따로따로 등록하고 지원해야된다.
- 시스템 호출은 스크립트에서 사용하기가 쉽지 않고, 파일시스템에서 직접 접근할 수도 없다.
- 시스콜 번호를 할당해야 하므로 주 커널 트리 외부에서 시스템 호출을 관리하고 사용하기 어렵다.
새로운 인터페이스의 시스콜 구현의 대안
- 장치 노드를 구현하고 read(),write() 함수를 해당 장치에 대해 호출한다. 장치의 일부 설정을 바꾸거나 설정정보를 얻고자 할 때는 ioctl()함수를 사용한다.
- 세마포어 같은 일부 인터페이스는 파일 서술자 형태로 표현이 가능하며, 파일을 다루는 방식을 그대로 사용할 수 있다.
- sysfs상의 적당한 위치에 해당 정보를 파일로 남긴다.
다음 포스팅에서는 리눅스 커널 인터럽트와 인터럽트 핸들러에 대해 살펴 보겠습니다.
(Linux kernel development. 3/E 참조)
'IT 놀이터 > Elite Member Tech & Talk' 카테고리의 다른 글
[6기 강북 이보희] 디지털 영상처리 - Recognition 편 (0) | 2014.11.04 |
---|---|
[6기 강남 송태현] Android Framework PowerManager 분석 (0) | 2014.11.02 |
[6기 강남 조유석] Network Flow - Ford-Fulkerson Algorithm (0) | 2014.11.02 |
[6기 대전 민창기] Control System #4 (0) | 2014.11.02 |
[6기 대전 민창기] Control System #3 (0) | 2014.11.02 |