YJcode

오늘은 SUSv3에서 정의한 기능 테스트 매크로와 표준 시스템 데이터형을 소개하겠다.

• 기능 테스트 매크로

시스템 호출과 라이브러리 함수 API의 동작에 대한 여러 가지 표준이 존재한다. 오픈 그룹 같은 포준 단체가 정의한 표준도 있고, 역사적으로 중요한 두가지 유닉스 구현인 BSD와 시스템 V 릴리스 4가 정의한 표준도 있다.

이식성 있는 응용 프로그램을 작설할 때는 헤더 파일이 특정 표준을 따르는지를 나타내는 정의가 있으면 편리할 때가 있다. 이를 위해 프로그램을 컴파일 할 때 아래 나열된 기능 테스트 매크로를 정의한다. 매크로를 정의하는 방법 중 하나는 프로그램 소스에서 헤더 파일을 선언하기 전에 매크로를 정의하는 것이다.

#define _BSD_SOURCE 1

또 다른 방법으로, 컴파일러의 -D 옵션을 쓸 수도 있다.

$ cc -D_BSD_SOURCE prog.c

다음과 같은 기능 테스트 매크로가 관련 표준에 정의되어 있으며, 따라서 이 매크로는 해당 표준을 지원하는 모든 시스템에서 이식성이 있다.

• _POSIX_SOURCE : 특정 값으로 정의되어 있으면, POSIX.1-1990과 ISO C 호환기능을 제공한다. 이 매크로는 _POSIX_C_SOURCE로 대체됐다.
• _POSIX_C_SOURCE : 1로 정의되어 있으면 _POSIX_SOURCE와 동일한 효과를 낸다. 199309 이상의 값으로 정의되어 있으면 POSIX.1b 기능도 제공한다. 199506 이상의 값으로 정의되어 있으면 POSIX.1c (스레드) 기능도 제공한다. 200112로 정의되어 있으면 POSIX.1-2001 기본 표준 기능도 제공한다. 200809로 정의되어있으면 POSIX.1-2008 기본 표준 기능도 제공한다.
• _XOPEN_SOURCE : 특정 값으로 정의되어 있으면 POSIX.1, POSIX.2, X/Open 기능을 제공한다. 500 이상의 값으로 정의되어 있으면 SUSv2 확장 기능도제공한다. 600 이상의 값으로 설정하면 추가적으로 SUSv3 XSI 확장기능과 C99 확장기능을 제공한다. 700 이상으로 설정하면 SUSv4 XSI 확장기능도 제공한다.

다음은 glibc 고유의 기능 테스트 매크로다.

• _BSD_SOURCE : 어떤 값이든 정의되어 있으면, BSD의 기능을 제공한다. 이 매크로를 정의하면 _POSIX_CSOURCE도 199506으로 정의된다. 명시적으로 이 매크로만 설정하면 표준이 상충되는 몇몇 경우에 BSD 표준을 따르게 된다.
• _SVID_SOURCE : 어떤 값이든 정의되어 있으면, 시스템 V 인터페이스 정의의 기능을 제공한다.
• _GNU_SOURCE : 어떤 값이든 정의되어 있으면, 이상의 모든 매크로를 설정해서 모든 기능을 제공할 뿐 아니라 다양한 GNU 확장 기능도 제공한다.

GNU C 컴파일러가 특별한 옵션 없이 실행되면 _POSIX_SOURCE, _POSIX_C_SOURCE=200809, _BSD_SOURCE, _SVID_SOURCE가 기본적으로 정의된다.

개별 매크로를 정의하거나 컴파일러를 표준 모드중 하나로 실행하면, 해당 기능만 제공된다. 예외가 하나 있는데, _POSIX_C_SOURCE가 정의되지 않고 컴파일러가 표준 모드중 하나로 실행되지 않으면, _POSIX_C_SOURCE가 200809로 정의된다.

여러 매크로를 동시에 정의하면 해당 기능이 모두 제공되므로, 예를 들어 다름과 같은 cc 명령을 이용해서 기본 설정과 동일한 매크로 설정을 명시적으로 선택할 수도 있다.

$ cc -D_POSIC_SOURCE -D_POSIX_C_SOURCE=199506 \
	-D_BSD_SOURCE -D_SVID_SOURCE prog.c

<features.h> 헤더파일과 feature_test)macros(7) 메뉴얼 페이지를 보면 각기능 테스트 매크로에 정확히 어떤 값이 할당되어 있는지를 알 수 있다.

_POSIX_C_SOURCE, _XOPEN_SOURCE, POSIX.1/SUS

POSIX.1-2001/SUSv3에는 _POSIX_C_SOURCE와 _XOPEN_SOURCE 기능 테스트 매크로만 규정되어 있으며, 호환 응용 프로그램의 경우 이 값들을 각각 200112와 600으로 정의하도록 요구한다. _POSIX_C_SOURCE를 200112로 정의하면 POSIX.1-2001 기본 규격호환성을 제공한다. _XOPEN_SOURCE를 600으로 정의하면 SUSv3 호환성을 제공한다. POSIX.1 - 2008/SUSv4의 경우도 이와 유사하게, _POSIX_C_SOURCE와 _XOPEN_SOURCE를 각각 200809와 700으로 정의해야 한다.

SUSv3에 따르면, _XOPEN_SOURCE를 600으로 설정하면 _POSIX_C_SOURCE를 200112로 설정했을때 제공되는 모든 기능을 제공해야 한다. 따라서 SUSv3호환성을 위해 응용 프로그램은 _XOPEN_SOURCE만 정의하면 된다. SUSv4도 이와 유사하게 _XOPEN_SOURCE를 700으로 설정하면 _POSIX_C_SOURCE를 200809로 설정했을때 제공되는 모든 기능을 제공해야 한다.

함수 프로토타입과 소스코드 예제의 기능 테스트 매크로

매뉴얼 페이지를 보면 헤더 파일의 특정 상수 정의나 함수 선언을 쓰려면 어떤 기능 테스트 매크로를 정의해야 하는지를 알 수 있다.

• 시스템 데이터형

프로세스 ID, 사용자ID, 파일 오프셋 등 여러가지 구현 데이터형이 표준 C 데이터형으로 표현되어 있다. 이런 정보를 저장하는 변수를 선언하기 위해 int나 long 같은 C의 기초 데이터형을 쓸 수도 있겠지만, 그렇게 하면 다음과 같은 이유로 유닉스 시스템 간의 이식성이 떨어진다.

• 이 기초 데이터형의 크가기 유닉스 구현마다 다르거나, 심지어 같은 구현이라도 컴파일환경에 따라 다를 수 있다. 그 뿐 아니라 같은 정보를 나타내더라도 구현에 따라 다른 데이터형을 쓰기도 한다. 예를 들어, 프로세스 ID가 한 시스템에서는 int이지만 다른 시스템에서는 long일 수도 있다.

• 같은 종류의 유닉스 구현에서도 버전에 따라 정보를 나타내는 데 쓰는 데이터형이 다를 수 있다. 리눅스상의 유명한 예는 사용자 ID와 그룹ID다. 리눅스 2.2까지는 이 값을 16비트로 나타냈는데, 리눅스 2.4부터는 32비트 값으로 바뀌었다.

이런 이식성 문제를 피하기 위해, SUSv3는 여러가지 표준 시스템 데이터형을 명시했고, 구현이 이 데이터형을 적절히 정의하고 사용하도록 요구했다. 이 데이터형은 C의 typedef 기능으로 정의됐따. 예를 들어 pid_t 데이터형은 프로세스 ID를 나타내는데, 리눅스 /x86-32에서는 다음과 같이 정의되어 있다.

typedef int pid_t;

표준 시스템 데이터형의 이름은 대부분 _t로 끝난다. 다른 헤더 파일에 정의되어 있는 것도 있지만, 상당수는 <sys/types.h> 에 정의되어 있다.

이식성을 위해 응용 프로그램은 이 데이터형 정의를 사용해야 한다. 예를 들어, 다음과 같이 선언하면 응용 프로그램은 모든 SUSv3 호환 시스템에서 올바르게 프로세스 ID를 나타낼 수 있다.

pid_t mypid;

아래 표는 시스템 데이터형 중 대표적인 몇가지의 예시이다.

프로그램의 상당수는 명령행 옵션과 인자에 따라 다르게 동작한다.

전통적인 유닉스 명령행 옵션은 하이픈( - ) 으로 시작해서, 옵션을 나타내는 한 글자와, 경우에 따라 추가 인자가 뒤따르기도 한다. 여기에 GNU 유틸리티는 하이픈 2개( -- ) 로 시작해서, 옵션을 타나내는 문자열과, 경우에 따라 추가 인자가 뒤따르는 확장 옵션 문법을 제공한다. 이 옵션을 파싱할때는 getopt() 라이브러리 함수를 쓰면 편리하다.

명령행 문법이 복잡한 프로그램에는 사용자를 위한 간단한 도움말 기능이 있다.

--help 옵션으로 실행하면, 프로그램이 명령행 옵션과 인자의 문법에 대한 사용법을 보여준다.

대부분의 프로그램에서, 공통적으로 필요한 정의가 담겨있는 헤더 파일과 공통 함수를 사용한다.

• 공통 헤더파일

아래 코드표의 헤더파일들은 거의 모든 프로그램이 매우 높은 빈도로 사용하는 헤더파일이다. 이 헤더 파일에는 여러 프로그램에서 쓰는 다른 많은 헤더 파일이 포함되어 있고, boolean 데이터형과 두 숫자중 최소값과 최대값을 구하는 매크로가 정의되어 있다.

							lib/tlpi_hdr.h

#ifdef TLPI_HDR_H
#define TLPI_HDR_H			//실수로 두번 포함하는 것을 방지한다.

#include <sys/types.h>			//여러 프로그램에 쓰이는 형 정의
#include <stdio.h>			//표준 I/O함수
#include <stdlib.h>			//표준 라이브러리 함수

#include <unistd.h>			//여러 시스템 호출 프로토타입
#include <errno.h>			//errno와 에러상수 정의
#include <string.h>			//흔히 쓰이는 문자열 처리 함수

#include "get_num.h"			//수 인자 처리함수 (getInt(), getLong()) 선언

#include "drror_functions.h"		//에러처리함수 선언

typedef enum { FALSE, TRUE } Boolean;

#define min(m,n) ((m) < (n) ? (m) : (n))
#define max(m,n) ((m) > (n) ? (m) : (n))

#endif

• 에러 진단 함수

앞으로 예제 프로그램에서 에러 처리를 쉽게 하기 위해, 아래에 선언되어 있는 에러 진단 함수를 사용한다.

							lib/error_functions.h
#ifdef ERROR_FUNCTIONS_H
#define ERROR_FUNCTIONS_H

void errMsg(const char *format, ...);

#ifdef __GNUC__

#define NORETURN __attribute__ ((__noreturn__))
#else
#define NORETURN
#endif

void errExit(const char *format, ...) NORETURN ;

void err_exit(const char *format, ...) NORETURN ;

void errExitEN(int errnum, const char *format, ...) NORETURN ;

void fatal(const char *format, ...) NORETURN ;

void usageErr(const char *format, ...) NORETURN ;

void cmdLineErr(const char *format, ...) NORETURN ;

#endif

시스템 호출과 라이브러리 함수의 에러를 진단할 때 errMsg(), errExit(), err_exit(), errExitEN()을 쓴다.

#include "tlpi_hdr.h"

void errMsg(const char *format, ...);
void errExit(const char *format, ...);
void err_exit(const char *format, ...);
void errExitEN(int errnum, const char *format, ...);

errMsg() 함수는 표준 에러로 메시지를 출력한다. 인자 목록은 printf()와 동일하지만, 출력 문자열 끝에 줄마꿈 문자가 자동으로 추가되는 것이 다르다. errMsg() 함수는 errno의 값에 따라, EPERM 같은 에러이름, strerror()가 리턴하는 에러 설명으로 이뤄진 텍스트, 그리고 인자 목록에 따라 포맷된 내용을 출력한다.

errExit() 함수는 errMsg()와 비슷하지만, 에러 메시지를 출력한 뒤 exit()를 호출해 프로그램을 종료시키거나, 환경 변수 EF_DUMPCORE가 비어 있지 않은 문자열로 정의되어 있으면 abort()를 호출해 디버그용 코어 덤프 파일을 만든다.

err_exit() 함수는 errExit()와 비슷하지만 다음과 같은 차이점이 있다.

• 에러 메싲지를 출력하기 전에 표준 출력 버퍼 내에 남아있던 내용을 모두 출력하지 않는다.
• exit()대신 _exit()를 호출해 프로세스를 종료시킨다. 이로 인해 stdio 버퍼내에 남아있던 내용을 출력하거나 종료 핸들러를 부르지 않고 프로세스를 종료한다.

err_exit()의 이런 차이점에 대해서는 차후 자세히 살펴몰 것이다. 우선은 err_exit()는 에러 발생시 종료해야 하는 자기 프로세스를 만드는 라이브러리 함수를 작성할 때 특히 유용하다고만 알고 있으면 된다. 이렇게 종료할 때는 부포 프로세스의 stdio 버퍼를 복사해서 만든 자식 프로세스의 stdio 버퍼에 남아 있던 내용을 모두 출력하거나 부모 프로세스가 설정한 종료 핸들러를 부르지 않고 종료해야 한다.

errExitEN() 함수는 errExit()와 비슷하지만, errno 값에 따라 에러 텍스트를 출력하는 대신, 인자 errnum으로 넘겨준 에러 번호에 따른 텍스트를 출력한다.

errExitEN()은 주로 POSIX 스레드 API를 채택한 프로그램에서 사용한다. 에러 발생시 -1을 리턴하는 전통적인 유닉스 시스템 호출과 달리, POSIX 스레드 함수는 에러번호를 리턴한다.

POSIX 스레드 함수의 에러는 다음과 같은 코드로 확인할 수 있다.

errno = pthread_create(&thread, NULL, func, &arg);
if (errno != 0) {
	errExit("pthread_create");
}

하지만 이 방법은 비효율적이다. 스레드를 쓰는 프로그램에서 errno는 바뀔 수 있는 lvalue를 리턴하는 함수 호출로 확장되는 매크로로 정의되어 있기 때문이다. 따라서 errno를 쓸 때마다 함수를 호출하게 된다. errExitEN()함수를 쓰면 다음과 같이 좀 더 효율적인 코드를 작성할 수 있다.

int s;

s = pthread_create(&thread, NULL, func, &arg);
if (s != 0) {
	errExitEN(s, "pthread_create");
}

또 다른 종류의 에러를 조사할 때는 fatal(), usageErr(), cmdLineErr() 를 쓸 수 있다.

#include "tlpi_hdr.h"

void fatal(const char *format, ...);
void usageErr(const char *format, ...);
void cmdLineErr(const char *format, ...);

• fatal() 함수는 errno를 설정하지 않는 라이브러리 함수를 포함하는 일반적인 에러를 조사할 때 쓴다. 인자 목록은 printf()와 같지만, 출력 문자열 끝에 줄바꿈 문자가 자동으로 추가되는 것이 다르다. 포맷된 메시지를 표준 에러로 출력하고는 errExit()를 호출해 프로그램을 종료시킨다.
• usageErr() 함수는 명령행 인자의 용법이 잘못됐을때 쓴다. printf() 스타일의 인자 목록을 받아서 포맷된 메시지 앞에 Usage:를 붙여서 표준 에러로 출력한 뒤 exit()를 호출해 프로그램을 종료시킨다.
• cmdLineErr()함수는 usageErr()와 비슷하지만 프로그램에 넘긴 명령행 인자의 에러를 알려줄 때 사용한다.

거의 대부분의 시스템 호출과 라이브러리 함수가 어떤 형태로든 성공 여부를 나타내는 상태값을 리턴한다. 이 상태값은 해당 호출이 성공했는지를 알기 위해 언제나 확인해야한다. 만약 실패했다면 적절한 동작을 취해야 한다. 최소한 프로그램이 뭔가 기대하지 않은 일이 발생했음을 알리는 에러 메시지라도 표시해야 한다.

이런 확인을 생략함으로써 타이핑 시간을 절약하고 싶은 유혹에 빠리기 쉽지만, 그것은 결국 절약이 아니다.

'실패할 리 없는' 시스템 호출이나 라이브러리 함수의 상태값을 확인하지 않은 것 때문에 수많은 디버그 시간이 낭비될 수 있다.

• 시스템 호출 에러 처리

각 시스템 호출의 메뉴얼 페이지에는 가능한 리턴값들이 나와 있고, 어느 값이 에러를 나타내는지도 나와 있다. 보통 -1을리턴하면 에러를 뜻한다. 따라서 시스템 호출은 다음과 같은 코드로 확인할 수 있다.

fd = open(pathname, flags, mode);
if(fd == -1) {
	//에러처리코드
}
. . .
if(close(fd) == -1) {
	//에러처리코드
}

시스템 호출이 실패하면 전역 정수 변수 errno를 특정 에러를 나타내는 양수로 설정한다. 헤더 파일 <errno.h>를 사용하면 errno 선언뿐만 아니라 다양한 에러 상수도 포함된다. 이 상수들의 이름은 모두 E로 시작한다. 각 메뉴얼 페이지의 errors 섹션에는 각 시스템 호출이 리턴할 수 있는 errno값의 목록이 나와 있다. 다음은 errno를 사용해서 시스템 호출 에러를 진단하는 간단한 예다.

cnt = read(fd, buf, numbytes);
if(cnt == -1) {
	if(errno == EINTR) {
    	fprintf(stderr, "read was interrupted by a signal \n);
    } else {
    	//기타 에러발생
    }
}

성공적인 시스템 호출과 라이브러리 함수는 절대 errno를 0으로 설정하지 않으므로, 이 변수는 이전의 함수 호출로 인해 0이 아닌 값을 갖고 있을 수도 있다. 더욱이 SUSv3는 성공적인 함수 호출이 errno를 0이 아닌 값으로 설정하는 것을 허용한다. 따라서 에러를 확인할 때는 언제나 함수의 리턴값이 에러를 나타내는지를 확인하고, 그 경우에만 errno를 통해 에러의 원인을 찾아야 한다.

몇몇 시스템 호출은 성공 시에도 -1을 리턴할 수 있다. 그런 호출에서 에러가 발생했는지를 알기 위해서는 호출 전에 errno를 0으로 설정하고, 호출 후에 다시 확인해야 한다. 호출이 -1을 리턴하고 errno가 0이 아니면, 에러가 발생한 것이다

시스템 호출이 실패한 뒤의 일반적인 동작은 errno 값에 따라 에러 메시지를 출력하는 것이다. 라이브러리 함수 perror()와 strerror()를 사용하면 편리하다.

#include <stdio.h>

void perror (const char *msg);

시스템 호출의 에러를 처리하는 단순한 방법은 다음과 같다.

fd = open(pathname, flags, mode);
if(fd == -1) {
	perror("open");
    exit(EXIT_FAILURE);
}

strerror() 함수는 인자 errnum으로 주어진 에러 번호에 해당하는 에러 문자열을 리턴한다.

#include <string.h>

char* strerror(int errnum);		//errnum에 해당하는 에러 문자열을 가리키는 포인터를 리턴

strerror()가 리턴한 문자열은 정적으로 할당되어 있을 수 있으므로, 이후의 strerror()에 의해 다른 값으로 바뀔 수 있다.

errnum이 알 수 없는 에러 번호를 담고 있으면, strerror() 는 Unknown errornnn 이라는 형태의 문자열을 리턴한다. 어떤 구현에서는 이런 경우 strerror()가 NULL을리턴하기도 한다.

perror()와 strerror() 함수가 로케일을 고려해서 동작하기 때문에 에러 설명이 현지어로 출력된다.

• 라이브러리 함수의 에러처리

다양한 라이브러리 함수가 실패를 알리기 위해 여러가지 데이터형의 여러가지 값을 리턴한다. 여기서는 라이브러리 함수를 다름과 같이 분류해봤다.

• 시스템 호출과 똑같이 에러 정보를 리턴하는 라이브러리 함수. -1을 리턴하고 errno에 구체적인 에러번호를 적는다. 이러한 함수의 예로는 파일이나 디렉토리를 삭제하는 remove() 가 있다. 이 함수의 에러는 시스템 호출의 에러와 똑같은 방법으로 진단할 수 있다.
• 에러 발생 시 -1을 리턴하지는 않지만 errno에 구체적인 에러 번호를 적는 라이브러리 함수, 예를 들어, fopen()은 에러 발생 시 NULL포인터를 리턴하지만 하부의 시스템 호출 결과에 따라 errno를 설정한다. perror() 와 strerror() 함수도 이 에러를 진단할 때 쓸 수 있다.
• errno를 전혀 쓰지 않는 나머지 라이브러리 함수. 에러의 발생 여부와 원인을 알아내는 방법은 함수마다 다르며 해당 함수의 메뉴얼 페이지에 적혀 있다. 이 함수의 경우 errno나, perror(), strerror()를 써서 에러를 진단하려고 하면 안된다.

유닉스 구현에 따라 표준 C 라이브러리 구현이 다를 수 있다. 리눅스에서 가장 널리 쓰이는 구현은 GNU C 라이브러리다.

때로 시스템의 glibc 버전을 판별해야 할 때가 있다. 쉘에서는 마치 실행 프로그램인 양 실행시켜보면 알 수 있다.라이브러리를 실행파일처럼 실행시키면, 버전 번호등을 출력한다.

$ /lib/libc.so.6

일부 리눅스 배포판에서는 GNU C 라이브러리가 /lib/libc.so.6 말고 다른 곳에 있을 수도 있다. 라이브러리의 위치를 찾는 방법 중 하나는 glibc와 동적으로 링크된 실행파일을 대상으로 ldd 프로그램을 실행하는 것이다. 출력된 라이브러리 의존관계 목록을 보고 glibc 공유 라이브러리의 위치를 찾을 수 있다.

$ldd myprog | grep libc

응용 프로그램이 시스템에 현존하는 GNU C 라이브러리의 버전을을 알아낼 수 있는 두가지 방법이 있다. 상수를 확인하거나 라이브러리 함수를 호출하는 것이다. 버전 2.0부터 glibc는 __GLIBC__ 와 __GLIBC_MINOR__라는, 컴파일할때 참조할 수 있는 두 상수를 정의한다. glibc 2.12가 설치된 시스템에서 이 상수들의 값은 각각 2와 12다.하지만 이들 상수는 한 시스템에서 컴파일해서 glibc버전이 상이한 다른 시스템에서 실행하는 프로그램의 경우에는 그 쓰임이 제한될 수밖에 없다. 이런 경우에 대비해서, 프로그램은 gnu_get_libc_version() 함수를 호출해 glibc의 버전을 실행 시에 알아낼 수 있다.

#include <gnu/libc-version.h>



const char* gnu_get_libc_version(void) ;

gnu_get_libc_version() 함수는 2.12 같은 문자열을 가리키는 포인터를 리턴한다.

라이브러리 함수는 표준 C 라이브러리를 구성하는 수많은 함수 가운데 하나일 뿐이다. 라이브러리 함수의 목적은 매우 다양해서, 파일을 연다든지, 시간을 사람이 읽을 수 있는 형태로 바꾼다든지, 문자열 2개를 서로 비교한다든지 하는 것들이 모두 포함된다.

상당수의 라이브러리 함수는 시스템 호출을 전혀 사용하지 않는다. 반면에 시스템 호출을 써서 구현된 라이브러리 함수도 있따. 예를 들어, fopen() 라이브러리 함수는 실제로 파일을 열기 위해 open() 시스템 호출을 사용한다. 라이브러리 함수는 종종 하부의 시스템 호출보다 사용하기 편리한 인터페이스를 제공하도록 설계됐다. 예를 들어 printf() 함수는 출력 서식과 데이터 버퍼링을 제공하지만, write() 시스템 호출은 단지 한 블록의 바이트를 출력할 뿐이다. 마찬가지로 malloc() 과 free() 함수는 다양한 관리 작업을 수행해서 이를 이용하면 하부의 brk() 시스템 호출보다 훨씬 쉽게 메모리를 할당하고 해제할 수 있다.

시스템 호출은 커널로의 관리된 진입점으로서, 이를 통해 프로세스가 커널에게 프로세스 대신 어떤 동작을 수행하도록 요청할 수 있다. 커널은 시스템 호출 API를 통해 광범위한 서비스를 제공한다. 이 서비스에는, 예를 들어 새로운 프로세스 생성, 프로세스간 통신용 파이프 생성 등이 있다.

시스템 호출이 동작하는데 있어 일반적이 사항은 다음과 같다.

• 시스템 호출은 프로세서의 상태를 사용자 모드에서 커널 모드로 변경해서 CPU가 보호된 커널 메모리에 접근할 수 있게 한다.
• 시스템 호출 목록은 고정되어 있다. 각 시스템 호출에는 고유한 숫자가 붙어있다.
• 각 시스템 호출은 사용자 공간에서 커널공간으로 가져올 정보를 나타내는 인자를 포함할 수 있다.

프로그래밍 관점에서 시스템 호출은 C 함수 호출과 매우 비슷하다. 하지만 막후에서는 시스템 호출을 실행하는 동안 여러 단계를 거치게 된다. 이를 보여주기 위해, 여기서는 특정 하드웨어(x86-32)상에서의 발생 순서를 따라가 보겠다.

1. 응용 프로그램이 C 라이브러리의 래퍼 함수를 호출해서 시스템 호출을 한다.
2. 래퍼 함수는 시스템 호출의 모든 인자를 시스템 호출 트랩 처리 루틴에게 전달해야 한다. 이 인자는 스택을 통해 래퍼에게 전달되지만, 커널에게 전달하려면 특정 레지스터에 넣어야 한다. 래퍼 함수는 인자를 이 레지스터로 복사한다.
3. 모든 시스템 호출이 같은 방법으로 커널에 진입하므로, 커널은 시스템 호출을 식별하는 방법이 필요하다. 이를 위해 래퍼 함수는 시스템 호출 번호를 특정 CPU 레지스터에 복사해넣는다.
4. 래퍼 함수는 트랩 기계어 명령을 실행하고, 이는 프로세서를 사용자 모드에서 커널 모드로 전환해 시스템의 트랩 벡터 0x80 이 가리키는 코드를 실행한다.
5. 0x80 트랩을 처리하기 위해, 커널은 system_call() 루틴을 호출한다. 이 핸들러는
   
   a) 레지스터 값들을 커널 스택에 저장한다.
   b) 시스템 호출 번호가 유요한지 확인한다.
   c)적절한 시스템 호출 서비스 루틴을 호출한다. 시스템 호출 서비스 루틴은 시스템 호출 번호를 시스템 호출 서비스 루틴 테이블에 대한 인덱스로 삼아서 찾는다.시스템 호출 서비스 루틴이 인자가 있으면 먼저 유효성을 확인한다. 예를 들어, 해당 주소가 사용자 메모리의 유효한 위치를 가리키는지 확인한다. 그 다음에 서비스 루틴이 필요한 작업을 수행하는데, 이 과정에서 인자가 가리키는 주소의 값을 변경하거나 사용자 메모리와 커널 메모리 사이에 데이터를 전송할 수도 있다. 마지막으로 서비스 루틴은 결과 샅애를 system_call() 루틴에게 리턴한다.
   d) 커널 스택에서 레지스터 값들을 복원하고 시스템 호출 리턴값을 스택에 넣는다.
   e) 래퍼 함수로 돌아오면서, 동시에 프로세서도 사용자 모드로 되돌린다.
   
   
6. 시스템 호출 서비스 루틴의 리턴값이 에러를 나타내면, 래퍼 함수는 전역 변수 errno를 그 값으로 설정한다. 래퍼 함수는 그 다음에 시스템 호출의 성공 여부를 나타내는 정수 리턴값을 제공하면서 호출 함수로 리턴한다.

위의 내용을 모두 이해해야 시스템 프로그램이 가능한 것은 아니다. 하지만 매우 간단한 시스템 호출이다로 상당량의 작업이 필요하므로, 시스템 호출에는 작지만 주목할 만한 오버헤드가 있다는 점을 유의해야 한다.