리눅스 커널 - 시스템 콜 (3)

시스템 호출 구현

 

<목적 정의 >

→ 이 시스템 콜의 중요 목적을 정의해야 한다. 가장 안좋은 예로는 ioctl() 함수를 들수있다 (이와 관련된 추가 설명은... 나중에)

<가능한 적은 개수의 인자사용, 깔끔하고 간단한 인터페이스>

<시간이 흐름에 따라 함수가 어떻게 바뀔지 예상하는 일...>

<방법을 제공해야지 정책을 제공하면 안된다>

 

매개변수 검사

시스템 호출은 모든 매개변수가 유효하고 적당한지 주의깊게 확인해야 한다.

가장 중요한 확인작업중 하나는 사용자가 제공한 포인터의 유효성을 확인하는 것이다.

• 포인터는 사용자 공간의 메모리영역을 가르키고 있어야한다.
  →프로세스는 커널을 속이고 직접 커널 공간의 데이터를 읽어서는 안된다.
• 포인터는 프로세스 주소공간의 메모리 영역을 가르키고 있어야 한다
• 읽는 경우라면 해당 메모리가 읽기 가능상태, 쓰는 경우라면 메모리가 쓰기 가능상태 실행하는 경우면 실행 가능상태
  → 프로세스가 메모리 접근 제한을 우회하면 안된다.

커널은 필요한 확인 작업을 수행하고 원하는 내용을 사용자 공간으로 가져오는 방법을 2가지 제공한다.

 

1. copy_to_user() : 사용자 주소 공간의 src에 있는 데이터를 복사

→ 매개변수 : 1 - 프로세스 주소공간의 목적지 메모리 주소, 2 - 커널공간의 원본 포인터, 3- 복사할 데이터의 바이트 크기

2. copy_to from() : 커널 공간에 있는 데이터를 사용자 주소 공간으로 복사

 

시스템 호출 컨텍스트

: 시스템 호출을 실행하는 동안 커널은 프로세스 컨텍스트 상태에 있다.

current 포인터는 시스콜을 호출한 프로세스인 현재 태스크릴 지칭

 

프로세스 컨택스트에서 커널은,

 1. 휴면 상태가 될 수 있으며

 2. 완전히 선점이 가능하다.

 

1. 휴면상태가 될 수 있다는 것은 시스템 호출이 커널의 대다수 기능을 사용할 수 있다는 의미

2. 프로세스 컨텍스트가 선점 가능하다는 사실은 사용자 공간고 마찬가지로 다른 작업에 선점 될 수 있다는 의미

 

→ 새로운 작업이 같은 시스템 호출을 실행할 수 있기 때문에 시스템 호출은 재진입이 가능해야 한다.

 

시스템 호출이 끝나고 반환되면 제어 권한은 system_call() 함수로 넘어가고 이 함수는 결국 사용자 공간으로 전환시켜 사용자 프로세스의 실행이 재개된다.

 

시스템 호출 등록의 마지막 단계

1. 시스템 호출 테이즐의 마지막에 항목을 추가, 시스템 호출을 지원하는 모든 아키텍처에 대해 이 작업을 수행
2. 지원하는 모든 아키텍처의 시스콜 번호를 <asm/unistd.h> 파일에 정의
3. 시스콜을 커널 이미지로 컴파일 한다. (Full compile)

시스템 호출의 장/단점 그리고 대안

 

장점

• 구현이 간단하고 사용이 쉽다
• 성능이 빠르다

단점

• 공식적으로 할당된 시스콜 번호가 필요
• 유연성이 떨어진다. 사용자 프로그램에 영향이 발생
• 아키텍처별로 별도로 관리해야 한다.
• 파일시스템에서 접근이 힘들다
• 주 커널 트리 외부에서 시스템 호출을 관리하기 어렵다

대안

• 장치노드를 구현하고 read(), write() 함수를 해당 장치에 호출, ioctl() 사용
• 세마포어 같은 일부 인터페이스는 파일 서술자 형태로 표현 가능
• sysfs, proc상의 적당한 위치에 파일로 정보를 남긴다.