최진희 <jhchoi@os.korea.ac.kr> 역.
2001년 4월 20일
이 문서의 목적은 FreeBSD 환경에서 KLD를 개발하고 이를 이용한 프로그래밍의 기본 지식을 소개하 는 데 있습니다. 따라서 예제를 중심으로(learn by example) 차근차근 진행해 나가면서 독자가 최대한 쉽게 KLD 코드를 작성할 수 있도록 일종의 뼈대 코드(skeleton code)도 제공하는 식으로 글을 전개해 나갈 것입니다. [동적 커널 링커(dynamic kernel linker)에 익숙치 않은 독자들을 위해 잠깐 설명하자면 KLD는 FreeBSD 3.1에 있었던 LKM(Loadable Kernel Modules)을 대체한 인터페이스로, 둘은 모두 시스템 관 리자가 수행 중인 시스템에 동적으로 어떤 기능을 추가/삭제할 수 있는 기능을 제공합니다. 이러한 특징을 이용하면 소프트웨어 개발자들은 작성한 커널 코드의 테스트하기 위해 시스템을 재부팅 할 필요가 없게 됩니다[ref. 1]. 대표적인 예로 디바이스 드라이버, 특히 네트워크 카드를 위한 드라이버 를 개발하는 상황을 들 수 있습니다. 한 가지 알아두어야 할 점은 KLD가 LKM의 부분 집합이라는 것입 니다. 즉, KLD라는 용어는 커널 모듈 시스템이 기존과 달라졌다는 사실을 부각시키기 위해 선택된 용어라는 뜻이죠. 좀 더 이해를 돕기 위해 여기서 Peter Wemm의 글을 인용하겠습니다. (IRC에서 있었던 "FreeBSD KLD vs LKM"이라는 꽤 심도 깊었던 논의에서 발췌합니다.) LKM 시스템은 재배치된 바이너리 데이터를 사용자 레벨의 링커를 사용하여 커널과 결합시킵니다. - KLD 시스템은 커널 내부에서 재배치가 이루어 집니다. 반면, LKM은 커널과 LKM 프로그램을 연결해 주는 어떤 특별한 자료 구조가 필요하며, lkm 드라이버가 이 자료 구조의 내용을 알고 있어야 합니다. 가령, VFS lkm이라면 vfs 테이블을 가리키는 자료 구조를 유지하고 있어야 한다는 말입니다. - LKM은 하나의 용도에 사용하기 위해 설계되었으며, LKM 코드를 실제 커널 코드로 변화시키는 것도 매우 어려운 작업입니다. - KLD는 여러 용도를 만족시킬 수 있는 보다 보편적인 구조를 지향합니다. 이런 이유로 하나의 파일이 0개 이상의 모듈을 포함할 수 있습니다. - 각 모듈 내부에는 자신을 초기화하고 등록시키는 매커니즘이 포함되어 있습니다. - KLD와 커널 코드는 같은 시기에 컴파일됩니다. - 커널 코드의 일부를 쉽게 KLD로 바꿀 수 있습니다. - 각 모듈 사이의 의존성과 버젼 관리는 모듈 레벨에서 이루어 집니다. 이 튜토리얼이 KLD 코드 작성법의 기초를 배우고 싶은 사람들을 대상으로 작성되었다는 사실에 다시 한번 주목해 주십시오. 따라서 이 문서를 제대로 이해하려면 FreeBSD 커널에 대한 지식이 어느 정도는 있어야 하며, C 프로그램도 어느 정도는 작성할 수 있어야 합니다. 마지막으로 이 문서의 모든 예제가 FreeBSD 4.0에서 작성되었다는 사실에 유의하십시오. 이 문서에서는 다음과 같은 주제를 다룹니다. - 모든 KLD 프로그램의 일반적 특성 - KLD 시스템 콜의 뼈대 코드 - KLD 캐릭터 디바이스 드라이버(character device driver)의 뼈대 코드 이 문서의 첫번째 목적은 KLD에 익숙한 사람들이 간단한 KLD 프로그램을 작성할 수 있도록 도와 주는 것이며, KLD 작성을 통해 KLD에 대해 보다 깊은 이해를 하여 이를 고급 수준의 작업에 활용하도록 하 는 것이 두번째 목적입니다.
Characteristics common to all KLDs
모든 KLD 프로그램에 반드시 포함되어야 하는 두개의 주요 함수/매크로가 있는데, 바로 다음과 같습니
다.
- 로드 핸들러 함수(Load Handler Function)
- DECLARE_MODULE 매크로 (Macro)
- Makefile을 이용한 손쉬운 컴파일
기본적으로 로드 핸들러 함수는 어떤 KLD 프로그램을 로드하고 언로드(unload)하는 역할을 담당하고
있습니다. 간단한 로드 핸들러 코드를 보면서 이야기를 진행하겠습니다.
static int
load_handler(module_t mod, int what, void* arg)
{
int err = 0;
switch(what){
case MOD_LOAD:
uprintf("KLD loaded successfully!\n");
break;
case MOD_UNLOAD:
uprintf("KLD unloaded successfully!\n");
break;
default:
err = EINVAL;
break;
}
return (err);
}
이 로드 핸들러(load handler)는 /usr/include/sys/module.h에 정의된 함수 포인터에 대응됩니다.
typedef int (*modeventhand_t)(module_t mod, int what, void* arg);
'module_t mod' 구조체는 모듈 구조체에 대한 포인터입니다. 이 구조체는 현재 로드된 모듈들의 연결 리
스트의 일부입니다. 따라서 로드된 다른 모듈들과 연결되며, KLD Id 번호 등의 유용한 다른 정보들도 포
함하고 있습니다.
'int what'은 modeventtype_t에 따라 각각 다음과 같은 값들 중 하나가 됩니다.
MOD_LOAD : 모듈이 로드될 때 설정합니다. (kldload)
MOD_UNLOAD : 모듈이 언로드(unload)될 때 설정됩니다. (kldunload)
MOD_SHUTDOWN : 모듈이 완전히 제거될 때 설정됩니다.
DECLARE_MODULE 매크로 역시 모든 KLD에서 사용되는 기본 요소입니다. 하지만 이 매크로가 항상
DECLARE_MODULE이란 이름으로 나타나는 것은 아닙니다. 특정 타입으로 모듈을 더 쉽게 정의하기
위해 다른 이름을 갖기도 한다는 것이죠. 하지만 본질적으로 같은 일을 수행합니다.
DECLARE_MODULE은 이미 언급했듯이 다음과 같은 매크로일 뿐입니다.
#define DECLARE_MODULE(name, data, sub, order) \
SYSINIT(name##module, sub, order, module_register_init, &data) \
struct __hack
이것은 /usr/include/sys/module.h에 정의되어 있습니다. 이제 각각의 매개 변수의 의미를 살펴 봅시다.
name : 일반적인 모듈의 이름으로 SYSINIT 호출에서 사용됩니다.
data : module_data 구조체에 대한 포인터로 이 구조체는 다음과 같은 두 가지 주요 아이템을 포함하고
있습니다.
* char* name;
공식적인 모듈의 이름으로 module 구조체에서 사용됩니다.
* modeventhand_t evhand;
이것이 로드 핸들러 함수의 포인터입니다. 따라서 이 필드는 작성하는 모듈의 로드 핸들러 함
수 이름이 되겠죠.
sub : 이것도 SYSINIT 매크로에게 바로 전달되는 매개 변수인데, 이 값은 /usr/include/sys/kernel.h에
있는 system_sub_id 나열 리스트의 값 중 하나가 됩니다. 나열 리스트의 값들은 시스템 초기화 인터페
이스(system startup interface)에게 알려진 값들입니다. 가령, 디바이스로 사용되는 KLD를 개발할 때는
SI_SUB_DRIVERS 타입이 지정될 수 있습니다.
order : 이 매개 변수는 SYSINIT의 호출 후에 사용되는데, 이 값은 서브 시스템에서의 KLS들의 초기화
순서를 나타냅니다. 이 필드의 유효 값들은 /usr/include/sys/kernel.h에 있는 sysinit_elem_order 나열
리스트의 값들 중 하나입니다.
그렇지만 상당히 유용한 두개의 다른 *_MODULE 매크로가 있는데, SYSCALL_MODULE과
DEV_MODULE이 그것입니다. 이 매크로들은 DECLARE_MODULE 매크로를 랩핑(wapping)한 것이죠.
이 매크로들은 1) 시스템 콜이나 디바이스 드라이버 모듈을 작성하기 쉽도록 설계되었을 뿐 아니라 2)
모듈 코드를 더 읽기 쉬운 방식으로 기술할 수 있게 해 줍니다. 만약 SYSCALL_MODULE 매크로가 사
용된 코드를 읽는다면 이 코드가 시스템 콜을 작성하기 위한 것이라는 사실을 그만큼 쉽게 알아 차릴
수 있겠죠.
SYSCALL_MODULE 매크로는 /usr/include/sys/sysent.h에 정의되어 있으며, 다음과 같은 매개 변수가
필요합니다.
name : DECLARE_MODULE에서의 name과 같은 의미로 사용됩니다.
offset : 시스템 콜의 번호를 넘기는데 사용됩니다. KLD를 사용하여 시스템 콜을 작성한다면 보통 그 시
스템 콜은 예약된 번호가 없을 경우가 많습니다. 이러한 경우, 이 매개 변수에 적합한 값은
NO_SYSCALL입니다. 이 값의 의미는 서브 시스템에게 기존 시스템 콜이 사용하지 않는 적절한 값을
찾아 넣어 달라는 의미입니다.
new_sysent : 새로운 시스템 콜을 위해 정의된 sysent 구조체를 의미합니다.
evh : modeventhand_t 로드 핸들러의 함수 포인터입니다.(위의 module_data 구조체에서의 evhand와
같습니다.)
arg : syscall_module_data 구조체에서 사용되는 값입니다. 이 매개 변수는 보통 NULL로 설정됩니다.
DEV_MODULE 매크로는 /usr/include/sys/conf.h에 정의되어 있으며, 다음과 같은 매개 변수가 필요합
니다.
name : 위의 두 *_MODULE 매크로에서와 같은 의미로 사용됩니다.
evh : modeventhand_t 로드 핸들러의 함수 포인터입니다.
arg : module_data 구조체에서 사용됩니다면 보통은 NULL로 설정합니다.
여러분의 모듈이 어떻게 개발되느야에 따라 다르겠지만 적어도 하나의 로드 핸들러와 *_MODULE 매크
로를 갖게 됩니다. 이 튜토리얼에서는 하나 이상의 로드 핸들러와 매크로가 필요한 상황은 고려하지 않
습니다.
대신 이러한 상황을 설명한 [ref.2]를 연결해 놓겠습니다. 참조 문서는 모듈에 대한 보다 심도 깊은 논
의를 하고 있으며, 다수의 훌륭한 예제 코드를 포함하고 있으므로 보다 수준 높은 예제를 원하는 독자에
게 추천합니다.
일반적으로 사용해온 Makefile에는 미리 정의된 변수의 집합이 있습니다. 이제 이 변수들을 설정하고
Makefile을 호출하기만 하면 모든 일은 끝납니다. 이러한 과정 때문에 KLD를 컴파일하기 위한
Makefile 작성 때문에 골머리 앓을 필요가 없습니다.
".include" 를 사용할 수 있는 Makefile은 /usr/share/mk에 있습니다.
하지만 우리가 관심있는 ".include"는 [ref.3]에 있습니다. 여러분 스스로 Makefile을 작성하기 전에
[ref.3]의 Makefile 상단에 있는 주석을 읽어 보시기 바랍니다.
여러분이 설정해야 하는 핵심 변수들은 몇 개 되지 않습니다.
SRCS : 소스들의 목록
KMOD : 빌드해야 하는 모듈의 이름
이 외에도 유용한 변수들은 많이 있습니다. ".include" 와 함께 Makefile을 사용하는 예제는 다음 페이
지부터 나오는 뼈대 코드와 함께 소개됩니다. 애써 중복 투자할 필요는 없습니다. 특히 Makefile과 같이
사소한 것에는 더욱 그렇죠.
KLD Syscall Implementation Skeleton
이 절에서는 동적 커널 링커 인터페이스(dynamic kernel linker interface)를 이용하여 시스템 콜을 추
가하는 아주 일반적인 예제가 소개됩니다.
소개될 코드는 양이 많진 않지만 중요한 코드가 포함되어 있습니다. 게다가 이 코드들은 시스템 콜을 추
가하는 모든 모듈에 공통적으로 포함됩니다. 코드는 크게 네 개의 주요 부분으로 나눕니다. 물론 로드
핸들러와 DECALRE_MODULE 매크로는 제외하고 나눈 것입니다.
- syscallname_args 구조체를 정의합니다.
- 시스템 콜이 될 함수는 int 형을 리턴 값으로 갖으며, 정적 함수(static function)으로 선언되어야
합니다.
- sysent 구조체의 멤버 변수들을 구현하려는 시스템 콜에 맞게 설정합니다.
- offset 변수를 NO_SYSCALL로 설정합니다.
커널 코드에서 발견할 수 있는 모든 시스템 콜들의 매개 변수 목록은 다음과 같습니다.
-struct proc*
-struct syscallname_args*
사용자 영역에서 시스템 콜로 전달되어야 하는 매개 변수들은 syscallname_args 구조체에 정의되어 있
습니다. 우리가 proc 구조체와 arguments 구조체에 대한 포인터를 넘기지 않고도 시스템 콜을 호출할
수 있는 이유는 이 작업을 libc가 대신해 주기 때문입니다.
우리는 동적으로 시스템 콜을 추가시키는 것이고, libc에게 우리의 시스템 콜을 호출해 줄 수 있는 기능
을 추가하지 않기 때문에 새로 작성한 시스템 콜을 호출하려면 syscall(2)을 사용해야 합니다.
이러한 내용은 예제를 소개하면서 조금 더 설명하게 될 것입니다.
이 예제에서 우리는 다음과 같은 시스템 콜 매개 변수를 사용합니다.
struct sc_example_args {
char *str;
int val;
};
매개 변수에 문자열 포인터(character string pointer)와 정수(integer)를 포함시킨 이유는 이 두 타입의
자료형을 시스템 콜로 넘기는 방법을 보여주기 위함입니다.(사용자 영역에서 커널 영역으로 데이터를 넘
기는 것이 대표적인 예겠죠.)
다음이 바로 예제 시스템 콜의 코드입니다.
static int
sc_example(struct proc *p, struct sc_example_args *uap)
{
char kstr[1024+1]; /* Holds kernel land copy of uap->str */
int err = 0; /* Generic return(err) */
int size = 0;
/*
* _IMPORTANT_:
*
* When one has a contiguous set of data and wish to copy this from
* userland to kernel land (or vice versa) the copy(9) functions
* are recommended for doing this.
*/
/*
* Copy the string located at the user land address uap->str to
* the kernel land address of &kstr.
*/
err = copyinstr(uap->str, &kstr, 1024, &size);
if (err == EFAULT)
return(err);
/*
* Print out the values we have gathered.
*
* uprintf() is a kernel land function that acts like printf().
* When using the printf() in kernel land, it uses the dmesg
* facility.. uprintf() on the other hand will output directly to
* the currently used tty.
*/
uprintf("The string passed was: %s\n", kstr);
uprintf("The value passed was: %d\n", uap->val);
return(0);
}
이 함수는 전달되는 매개 변수(하나의 문자열과 정수)만을 넘겨 받은 후, 그 값을 현재 작업하고 있는
tty(시스템 콜을 호출한 프로그램이 수행되고 있는 터미널)에 출력합니다.
다음에 해야 할 일은 시스템 콜을 위해 sysent 구조체의 내용을 채워넣는 일입니다. Sysent 구초제는
/usr/include/sys/sysent.h에 정의되어 있으며, 다음과 같습니다.
struct sysent {
int sy_narg;
sy_call_t *sy_call;
};
각 시스템 콜마다 정의된 sysent 구조체를 갖고 있습니다. 'int sy_narg'는 정의될 시스템 콜에게 얼마나
많은 매개 변수가 넘어올 것인지를 결정하는 변수입니다. 우리의 뼈대 코드에서는 2개의 매개 변수만이
넘어옵니다.(char* str과 int val) 따라서 sy_narg는 2로 설정합니다. 'sy_call_t* sy_call'은 static int
syscall에 대한 함수 포인터입니다. Sy_call_t는 /usr/include/sys/sysent.h에 정의되어 있으며 다음과 같
습니다.
typedef int sy_call_t __P((struct proc *, void *));
따라서 우리 코드에서는 다음과 같이 설정될 것입니다.
static struct sysent sc_example_sysent = { 2, /* Number of parameters for our system call. */
sc_example /* A function pointer to our new system call. */ };
이전의 설명을 기억한다면 SYSCALL_MODULE 매크로에게 넘어온 offset이라는 매개 변수가 있었다는
사실을 알고 있을 것입니다. 이 매개 변수는 선언하고 있는 시스템 콜을 호출하는데 사용될 값을 담고
있습니다. 하지만 보통 KLD 같은 것을 이용하여 동적으로 시스템 콜을 생성할 때에는 특정한 값을 정하
여 넘기지 않는 것이 좋습니다. 보통 이 값을 NO_SYSCALL로 설정하는 것이 좋은데, 이 값의 의미는
"할당 가능한 다음 시스템 콜 값을 찾아달라"는 것입니다.(이 내용도 이미 설명했었습니다.) 따라서 매크
로에게 offset 값으로 NO_SYSCALL만을 넘기면 시스템 콜 번호의 문제는 해결될 것입니다. 하지만 어
떤 정적 변수 값을 NO_SYSCALL로 설정한 후 그 변수를 넘기는 방식이 더 추천되는데, 이렇게 하면
모듈을 로드할 때 이 변수의 값이 무엇으로 설정되어 있는지를 알 수 있기 때문입니다. 이 매크로는
NO_SYSCALL을 담고 있던 변수를 시스템이 할당해 준 번호로 변경시킵니다. 시스템에 이미 정의되어
있는 시스템 콜과 그 호출 번호는 /usr/include/sys/syscall.h에 정의되어 있습니다.
이런 이유로 우리는 코드의 다음 라인을 다음과 같이 작성할 것입니다.
static int syscall_num = NO_SYSCALL;
NO_SYSCALL은 /usr/include/sys/sysent.h에 정의되어 있는데, (-1)로 설정되어 있습니다.
우리는 이미 하나의 시스템 콜을 구현하는데 필요한 모든 부분을 완성했습니다. 따라서 남은 부분은 로
드 핸들러를 작성하고 SYSCALL_MODULE 매크로 호출하는 것 뿐입니다.
static int
load_handler(struct module *m, int what, void *arg)
{
int err = 0;
switch (what) {
case MOD_LOAD:
/* Print out syscall_num so we know the value to call */
printf("System call loaded at slot: %d\n", syscall_num);
break;
case MOD_UNLOAD:
printf("System call unloaded from slot: %d\n", syscall_num);
break;
default:
err = EINVAL;
break;
}
return(err);
}
SYSCALL_MODULE(sc_example,
&syscall_num,
&sc_example_sysent,
load_handler,
NULL);
이제 우리의 뼈대 코드가 완성되었습니다. (주석없는 코드는 [ref. 4]에서 얻을 수 있습니다.) 이제 컴파
일할 준비가 다 되었군요. 그렇다면 다음과 같이 간단한 Makefile을 작성합시다.
SRCS=sc_example.c
KMOD=sc_example
.include <bsd.kmod.mk>
그리고 make라고 타이핑하십시오. 이제 컴파일이 끝났다면 루트 권한으로 다음과 같이 입력하세요.
'kldload ./sc_example.ko'
지금까지의 과정에 어떤 에러가 없었다면 다음과 같은 출력물을 볼 수 있을 것입니다.
System call loaded at slot: 210
여기에서 논의되지 않은 점은 시스템 콜이 로드된 후, 어떻게 이 시스템 콜을 호출하는가 하는 것입니다.
하지만 [ref.4]에서 제공되는 코드를 참조하면 이 시스템 콜을 호출하는 몇 가지 다른 방법의 예를 볼
수 있을 것입니다. 또한 syscall(2)의 man page도 읽어 보시기 바랍니다.
Character Device KLD Implementation Skeleton
대부분의 유닉스 시스템에서 가장 유용하게 사용되는 디바이스의 형태는 캐릭터(character) 디바이스입
니다. 이러한 형태의 디바이스는 물리 디바이스(physical device)를 나타내는데 사용되는 것 뿐 아니라
커널의 특정 부분을 읽고, 쓰고, 플래그를 설정하기 위한 인터페이스로 사용되기도 합니다. 가령, 캐릭터
디바이스를 설정하여 네트워크 트래픽(network traffic)과 관련된 디바이스로부터 데이터를 읽어 오는 것
도 가능합니다.
시스템 콜 구현과 같이 캐릭터 디바이스의 제작도 예제 중심으로 진행될 것입니다. 이 디바이스가 가진
기능은 실로 미약하지만 모든 캐릭터 디바이스의 일반적인 특성을 파악하는 데는 무리가 없는 예일 것
입니다. 앞으로 진행될 설명을 통해 여러분이 캐릭터 디바이스의 제작이 그렇게 어려운 것은 아니며, 이
디바이스를 제작하여 사용하는 것이 상당히 유용하다는 사실을 깨달을 수 있으면 합니다.
다음과 같은 점들은 모든 캐릭터 디바이스의 구현에 공통적인 부분입니다.
- 원형 디바이스 함수들(prototype device functions)
- cdevsw 구조체 선언
- 선언된 cdevsw 구조에 따른 함수들
- 로드 핸들러와 DEV_MODULE 매크로
위와 같은 것들이 앞으로 만들어 나갈 뼈대 코드에 포함될 내용들입니다. 시스템 콜 예제 코드와 마찬가
지로 주석 없는 코드를 원한다면 [ref.4]를 참조하시기 바랍니다. 컴파일하고 실행시켜 보는 것이 코드
를 분석하는데 상당히 큰 도움이 된다는 사실을 기억하십시오.
여기에서 프로토타입(prototype)을 만들 함수는 단지 새로운 디바이스에 바로 접근하기 위해 호출되는
함수들이며, cdevsw 구조체에 포함됩니다. 이러한 함수로는 디바이스를 열고, 닫고, 쓰고, 읽는 함수를
들 수 있습니다.
d_open_t example_open;
d_close_t example_close;
d_read_t example_read;
d_write_t example_write;
cdevsw 구조체에는 우리가 구현하고 있는 캐릭터 디바이스와 관련 있는 많은 것들이 정의됩니다. 이 구
조체는 /usr/include/sys/conf.h에 정의되어 있으며, 다음과 같습니다.
struct cdevsw {
d_open_t *d_open; /* Func. pointer to dev open function */
d_close_t *d_close; /* Func. pointer to dev close function */
d_read_t *d_read; /* Func. pointer to dev read function */
d_write_t *d_write; /* Func. pointer to dev write function */
d_ioctl_t *d_ioctl; /* Func. pointer to dev ioctl function */
d_poll_t *d_poll; /* Func. pointer to dev poll function */
d_mmap_t *d_mmap; /* Func. pointer to dev mmap function
*/
d_strategy_t *d_strategy; /* Func. pointer to dev strategy func. */
const char *d_name; /* Device name in /dev */
int d_maj; /* Device major value */
d_dump_t *d_dump; /* Func. pointer to dev dump function */
d_psize_t *d_psize; /* Func. pointer to dev psize function */
u_int d_flags; /* D_TAPE, D_DISK, D_TTY, D_MEM */
int d_bmaj; /* Block Device major value (used by D_DISK) */
};
구조체 내의 모든 함수 포인터가 정의되어야 하는 것은 아닙니다. 이유가 뭘까요? 여러분이 쓰기만 가
능한 디바이스를 원한다고 가정해 봅시다. 이 경우, 단지 파일 허가권(permission)을 설정하는 것 외에
cdevsw 구조체를 선언할 때 d_read 포인터를 noread로 설정할 수 있을 것입니다.(실제론 비워놓는 것
이죠.) 우리의 예제 코드에서는 단지 d_open, d_close, d_write 함수만을 설정하여 추후의 논의를 단순화
하겠습니다. 그렇다면 우리의 cdevsw 구조체는 다음과 같은 모습을 하게 되겠죠.
static struct cdevsw example_cdevsw = {
example_open,
example_close,
example_read,
example_write,
noioctl,
nopoll,
nommap,
nostrategy,
"example",
33, /* /usr/src/sys/conf/majors */
nodump,
nopsize,
D_TTY,
-1
};
결국 "no*"로 시작되는 선언을 제외한다면 d_open_t, d_close_t, d_read_t, d_write_t를 위한 함수만이
선언되어 있는 셈입니다. 다른 캐릭터 디바이스의 코드를 원한다면 [ref. 5]를 참조하십시오. 이 예제에
서는 d_open_t, d_close_t, d_read_t, d_write_t를 위한 간단한 예제 함수만이 정의됩니다. 또 하나, 주
번호(major value)가 33인지 확인해 보시기 바랍니다. 33은 예제 목적으로 예약된 주 번호 중 하나입니
다. 이 외에 다른 예제 번호를 확인하고 싶거나 실제 사용될 디바이스를 위해 할당된 주 번호 값을 확인
하고 싶다면 /usr/src/sys/conf/majors 파일을 살펴 보시기 바랍니다.
이 예제의 기본 의도는 디바이스 드라이버와의 상호 작용이 어떻게 이루어 지는가를 보여 주는 것입니
다. 이러한 이유로 이 드라이버에서의 코드 흐름은 다음과 같은 순서로 설정했습니다.
open(2) -> write(2) -> read(2) -> close(2).
우리는 먼저 /dev/ 디렉토리에 있는 디바이스를 열 것입니다. 그 후, write(2) 시스템 콜을 사용하여 짧
은 문자열을 씁니다. 우리가 디바이스에 쓴 문자열은 어떤 정적 버퍼(static buffer)에 저장될 것이고, 이
값은 read(2) 시스템 콜을 거쳐 접근될 것입니다. 이제 이 디바이스를 닫아 더 이상 읽거나 쓸 수 없도
록 만듭니다.
/* Stores string recv'd by _write() */
static char buf[512+1];
static int len;
/*
* Used as the variable that is the reference to our device
* in devfs... we must keep this variable sane until we
* call kldunload.
*/
static dev_t sdev;
/*
* This open function solely checks for open(2) flags. We are only
* allowing for the flags to be O_RDWR for the purpose of showing
* how one could only allow a read-only device, for example.
*/
int
example_open(dev_t dev, int oflags, int devtype, struct proc *p)
{
int err = 0;
memset(&buf, '\0', 513);
len = 0;
uprintf("Opened device \"example\" successfully.\n");
return(err);
}
/*
* Simply "closes" our device that was opened with example_open.
*/
int
example_close(dev_t dev, int fflag, int devtype, struct proc *p)
{
memset(&buf, '\0', 513);
len = 0;
uprintf("Closing device \"example.\"\n");
return(0);
}
/*
* The read function just takes the buf that was saved
* via example_write() and returns it to userland for
* accessing.
*/
int
example_read(dev_t dev, struct uio *uio, int ioflag)
{
int err = 0;
if (len <= 0) {
err = -1;
} else { /* copy buf to userland */
err = copystr(&buf, uio->uio_iov->iov_base, 513, &len);
}
return(err);
}
/*
* example_write takes in a character string and saves it
* to buf for later accessing.
*/
int
example_write(dev_t dev, struct uio *uio, int ioflag)
{
int err = 0;
err = copyinstr(uio->uio_iov->iov_base, &buf, 512, &len);
if (err != 0) {
uprintf("Write to \"example\" failed.\n");
}
return(err);
}
지금까지 살펴 본 바와 같이 간단한 캐릭터 디바이스 드라이버를 작성하는 것은 매우 쉬운 일이다. 특히,
sysctl로 가능한 양 이상으로 많은 데이터를 커널과 교환하고 싶다면 이 방법은 멋진 해결책이 될 것입
니다.
다음에 나올 코드는 실제 KLD를 로드하고 언로드할 때 사용되는 함수입니다. 디바이스 드라이버의 경우,
로드하고 언로드할 때 시스템 콜에서는 하지 않았던 특별한 작업을 수행해야 합니다. 즉, MOD_LOAD
시 make_dev를 사용하여 devfs에 우리의 디바이스를 등록해야 합니다. devfs는 Device File System의
약어로서 FreeBSD 커널 내부에 있는 디바이스 공간에 접근할 수 있도록 해 줍니다. 또한
MOD_UNLOAD 시에는 destroy_dev를 호출해야 하는데, 매개 변수로는 make_dev가 리턴해 준 dev_t
변수가 사용되어야 합니다.
/*
* chardev_example_load()
*
* This is used as the function that handles what is to occur
* when the KLD binary is loaded and unloaded via the kldload
* and kldunload programs.
*/
static int
chardev_example_load(struct module *m, int what, void *arg)
{
int err = 0;
switch (what) {
case MOD_LOAD: /* kldload */
sdev = make_dev(&example_cdevsw, /* explained below */
0,
UID_ROOT,
GID_WHEEL,
0600,
"example");
printf("Example device loaded.\n");
break;
case MOD_UNLOAD:
destroy_dev(sdev); /* explained below */
printf("Example device unloaded.\n");
break;
default:
err = EINVAL;
break;
}
return(err);
}
다른 종류의 KLD를 만들 때처럼 기본적으로 *_MODULE 매크로를 사용하여 어느 함수가 로드 핸들러
인지와 이 모듈에 접근할 때 사용할 이름을 알려 주어야 합니다.
DEV_MODULE(chardev_example, chardev_example_load, NULL);
이제 매우 간단한 캐릭터 디바이스의 뼈대 코드가 완성되었습니다. 이제 남은 일은 Makefile을 만들고
/dev 디렉토리에 디바이스를 실제로 생성하는 일 뿐입니다. 이 작업 역시 결코 어려운 작업이 아닙니다.
# cd /dev
# mknod example c 33 0
# ls -al | grep example
crw-r--r-- 1 root wheel 33, 0 Aug 14 04:40 example
#
위의 과정이 끝나면 kldload를 수행한 후 /dev/example에 open(), close(), read(), write() 호출을 수행
해 보십시오. 테스트가 끝난 후 kldunload를 수행할 텐데, 이 전에 반드시 close()를 호출하여 디바이스
를 닫아 주어야 한다는 사실을 기억하시기 바랍니다.
예제의 컴파일 가능한 코드는 [ref. 4]를 보시기 바랍니다.
Conclusion 이것으로 FreeBSD KLD 코딩 시스템에 대한 소개를 마무리 해야 할 것 같습니다. 글의 초반부에 말했 듯이 꽤 짧은 소개였지만 당장 KLD 프로그램을 작성하고자 하는 사람에게는 꽤 유용한 정보였으리라 생각합니다. 이 글은 THC [ref. 2]를 참조로 하여 작성되었는데, THC는 KLD를 좀 더 자세히 배울 수 있는 훌륭한 기사입니다. 이외에 더 많은 예제 코드를 원하는 독자들은 [ref. 4]를 참조하시기 바랍니다. [ref. 4]에는 이 튜토리얼에서 설명한 것 이상의 다양한 예제 코드가 소개됩니다. Contact 이 튜토리얼의 어느 부분이라도 저자에게 궁금한 점이 있다면 문의해 주시기 바랍니다. E-Mail : awr@blackops.org References 1. kld(4) man page. [Much help] 2. THC's FreeBSD Kernel Attack paper. [Good place for taking your white hat and turning it black] 3. /usr/share/mk/* [Key for any Makefile creation under FreeBSD] 4. Example code from tutorial [Location of the examples plus more code.] 5. /usr/share/example/kld/cdev/ [Old example in FreeBSD tree] Recognition Peter Wemm - Discussion regarding LKM->KLD changes + long quote [intro] Eivind Eklund - style(9) harassment. Daniel O'Connor - Random comments.