Ori Pomerantz는 Yoav Weiss의 많은 조언과 문서 공개전에 문서에서 잘못된 부분들을 찾아 준 것에 감사의 말을 전한다. 또한 네덜란드의 Frodo Looijaard, 뉴질랜드의 Stehpen Judd, 스웨덴의 Ahltorp, 그리고 캐나다 퀘벡의 Emmanuel Papirakis에게도 감사한다.

내가 이 문서를 관리할 수 있도록 해준 점에 대해 Ori Pomerantz에게 감사한다. 그에게 있어 이것은 상당한 노력이었다. 내가 이 문서에 작업한 것을 그가 좋아하길 바란다.

나를 지도해준 Jeff Newmiller와 Rhonda Bailey에게도 감사한다. 그들이 바쁨에도 불구하고 인내심을 가지고 나에게 그들의 경험을 전해 주었다. David Porter는 LaTeX 소스를 DocBook으로 컨버팅하는 지루하고 골치 아픈 직업을 가지고 있지만 누군가는 그 일을 해야만 한다. David에게도 감사한다.

http://www.tldp.org/LDP/lkmpg/www.kernelnewbies.org 의 사람들에게도 감사를 한다. 특히, kernelnewbies.org에 드나들며 초보들 가르치는 것 외에도 할 일이 무척 많을 것임이 분명한 Mark McLoughlin과 John Levon에게 감사를 보낸다. If this guide teaches you anything, they are partially to blame. 만약 이 문서가 당신에게 별 의미가 없다면 그들에게도 책임이 있다(역주: 그만큼 그들의 역할이 중요했음 ).

Ori와 나는 Richard M. Stallman과 Linus Tovalds에게 성능 좋은 OS를 사용하게 해준 것과 그것이 어떻게 작동하는지 자세히 알 수 있는 기회를 준 점에 대해 감사한다. 나는 Linus를 만난 적도 없고, 앞으로도 못 만나겠지만, 그는 나의 인생에 상당한 변화를 주었다.

다음은 나에게 좋은 제안을 하거나 오류수정의 메시지를 보낸 사람들이다. Ignacio Martin and David Porter

Ori's original document was good about supporting earlier versions of Linux, going all the way back to the 2.0 days. I had originally intended to keep with the program, but after thinking about it, opted out. My main reason to keep with the compatibility was for Linux distributions like LEAF, which tended to use older kernels. However, even LEAF uses 2.2 and 2.4 kernels these days.

Both Ori and I use the x86 platform. For the most part, the source code and discussions should apply to other architectures, but I can't promise anything. One exception is Chapter 12, Interrupt Handlers, which should not work on any architecture except for x86.

당신은 커널 모듈을 작성하려고 한다. C를 알고 프로세스로 작동하는 일반적인 프로그램을 작성해 봤고 이제는 어디서 실질적인 작업이 행해지는지, 하나의 와일드 포인터가 파일 시스템을 완전히 지울 수 있고 코어 덤프가 시스템의 리부팅을 의미한다는 것을 알고 있다.

커널 모듈이란 정확히 무엇인가? 모듈이란 요구에 따라 커널에 적재 되거나 해제 될 수 있는 코드다. 시스템의 재가동 없이 커널의 기능을 확장을 가능케하는 것이다. 예로 모듈의 한 종류는 디바이스 드라이버다. 그리고 그것은 시스템에 연결된 하드웨어에 커널이 접근할 수 있도록 해 준다. 모듈이 없다면 우리는 모놀리틱 커널을 다시 빌드 해야 하며, 커널 이미지에 새로운 기능을 직접적으로 추가 시켜야 한다. 대규모 커널에서는, 우리가 원하는 새로운 기능을 추가 하기 위해서 매번 커널을 다시 빌드해야 하고, 다시 부팅해야하는 단점을 갖게 된다.

lsmod를 실행함으로써 당신은 이미 커널에 적재되있는 모듈을 볼 수 있으며, lsmod는 /proc/modules 파일을 읽어 정보를 얻어 온다.

모듈은 커널에서 어떻게 자신의 위치를 찾아낼까? 커널 내부에 존재하지 않는 특징을 커널이 알 필요가 있을 때, 커널 모듈 데몬인 kmod(이전 버전의 리눅스에서는 kerneld로 알려져 있다.) 모듈을 로드 시키기 위해 modprobe를 실행 시킨다. modprobe에 다음의 두 형태로 문자열이 전달된다.

• softdog 혹은 ppp 같은 모듈이름
• char-major-10-30 같은 일반적인 아이덴티파이어
  
  

modprobe가 일반적인 아이덴티파이어를 전달 받는다면, 그것은 /etc/modules.conf 파일에서 그 문자열을 찾는다. 다음과 같은 알리어스 행을 찾는다면

 alias char-major-10-30 softdog

일반적인 아이덴티파이어는 softdog.o라는 모듈을 참조한다는 사실을 알게 된다.

다음으로 modprobe는 /lib/modules/version/modules.dep 파일을 조사해서 다른 모듈이 요구되는 모듈이 적재되기 전에 먼저 적재되야 하는가를 본다. 이 파일은 depmod -a 에 의해 생성되며, 모듈의 의존성을 담고 있다. 예를 들어 msdos.o는 fat.o모듈이 먼저 커널에 적재된 상태를 요구한다. 요청된 모듈이 사용하는 심볼(변수나 함수)을 다른 모듈이 정의 했는가라는, 다른 모듈에 대한 의존성을 갖는다.

마지막으로 modprobe는 선행 모듈을 커널에 적재하기 위해 insmod를 사용하고, 요구된 모듈을 적재한다. modprobe는 insmod에 표준 모듈 디렉토리인 /lib/modules/version/을 사용하도록 지시한다. insmod는 모듈의 위치에 대한 정보를 전혀 모르게 되있다. 반면에 modprobe는 모듈의 기본 위치를 알고 있다. 예를 들어 msdos모듈을 적재하기 원한다면 다음의 두 가지를 실행해야 한다.

insmod /lib/modules/2.5.1/kernel/fs/fat/fat.o
insmod /lib/modules/2.5.1/kernel/fs/msdos/msdos.o

혹은 "modprobe -a msdos"를 실행하자.

리눅스는 modprobe, insmode, depmod를 modutils혹은 mod-utils라 불리는 패키지로 제공한다

이장을 마치기 전에 /etc/modules.conf를 살펴보자.

#This file is automatically generated by update-modules
path[misc]=/lib/modules/2.4.?/local
keep
path[net]=~p/mymodules
options mydriver irq=10
alias eth0 eepro

#으로 시작하는 행은 주석이며, 빈 행은 무시된다.

path[misc] 행은 modprobe에 /lib/modules/2.4.?/local 디렉토리에서 misc 모듈에 대한 경로를 찾아 대체하도록 한다. 보듯이, 쉘 메타 캐릭터가 사용 가능하다.

path[net] 행은 modprobe로 하여금 net 모듈을 ~p/modules/ 디렉토리에서 찾도록 한다. 그러나 pathnet에 바로 선행되는 “keep”은 modprobe에게 misc모듈에서 한 것처럼 표준 검색 경로를 대체하지 않고, 해당 디렉토리를 net모듈을 찾을 때 표준 검색 경로로 추가하도록 한다.

kmod가 일반적인 아이덴티파이어인 ‘eth0’를 적재하라는 요구할 때마다, eepro.o를 적재하라고 한다.

/etc/modules.conf 에서 "alias block-major-2 floppy"같은 행은 발견하지 못할 것이다. 왜냐햐면, modprobe는 대부분의 시스템에서 사용되는 표준 드라이버들에 대해 알고 있기 때문이다.

이제 모듈이 어떻게 커널에 적재되는지 알았을 것이다. ‘stacking modules’라고 부르는 모듈에 의존적인 모듈을 작성한다면 몇 가지 더 언급할 것들이 있다. 이것은 다음으로 미룬다. 상대적으로 고 난이의 쟁점을 다루기 전에 다뤄야 할 부분이 많이 있다.

코드를 파헤치기 전에 우리가 다뤄야할 몇몇 주제가 더 있다. 모든 사람의 시스템이 상이하고 그들만의 관습이 있다. “hello world” 프로그램을 컴파일하고 올바르게 적재하는 것은 때론 trick(?)일수 있다. 처음 몇몇 장애를 극복하고 나면, 순풍에 돛을 단 듯 진행될 것이라 생각한다.

CONFIG_MODVERSIONS를 커널에서 활성화 시키지 않았다면, 특정 커널에서 컴파일한 모듈은 다른 커널로 부팅한 시스템에는 적재 되지 않는다. 이문서 후반부 까지는 모듈 버전에 관한 문제를 다루지 않을 것이다. 이 문서의 예제는 modversioning기능을 활성화한 커널을 사용한다면 작동하지 않을 것이다. 대부분의 배포판 커널은 이 기능을 활성화 시킨 상태로 나온다. 만약 모듈을 적재할 때 버전 문제로 에러가 난다면 modversioning 기능을 비활성화 시킨 후 커널을 다시 컴파일 해야 할 것이다.

이 문서에 나온 모든 예제를 타이핑하고 컴파일하고 적재해보기를 강력히 권하다. console에서 작업하기 역시 권한다. X 환경에서의 작업을 하지 마라.

모듈은 printf()처럼 화면에 출력을 하지 못하고 로그 정보와 경고들을 콘솔로만 출력한다. 만일 xterm에서 모듈을 적재한다면, 정보와 경고들은 당신의 로그 파일에만 기록될 것이다. 로그 파일을 확인 하기 전까지는 그것을 보지 못할 것이다. 즉각적인 정보를 위해서 모든 작업을 콘솔에서 하라.

종종 리눅스는 표준이 아닌 방식으로 다양하게 패치되서 배포되고 그것은 문제를 야기한다.

더 흔한 문제는 몇몇 배판들이 불완전한 커널 헤더를 가지고 배포된다는 점이다. 당신의 코드를 컴파일 할 때 리눅스 커널의 다양한 헤더 파일을 사용해서 컴파일 해야 할 것이다. 머피의 법칙은 모듈이 작동하기에 필요한 헤더만 빠져있다고 말한다.(썰렁 조크-_-“ – 필자가 쓴것임) 이런 문제를 피하기 위해서는 리눅스 커널 미러 사이트에서 다운 받아 컴파일하고 부팅시켜 시스템을 사용할 것을 강력히 권한다. 자세한 사항은 Linux Kernel HOWTO를 참고하기 바란다.

역설적이지만 이것 역시 문제를 만든다. 기본적으로, 당신의 시스템에 있는 GCC는 당신이 설치한 버전의 커널 헤더파일을 찾는 것이 아니고 기본으로 설치됐던 커널 헤더(보통 /usr/src/)를 찾을 것이다. 이것은 gcc의 -l 옵션을 사용해서 수정할 수 있다.

원시 프로그래머가 처음으로 원시 컴퓨터에 첫 프로그램을 새겨 넣었을 때, 그것은 ‘Hello World’라는 문자를 양떼 그림에 새겨 넣은 프로그램이었다. 로마의 프로그램 책은 ‘Salut Mundi’(hello world의 로마어인 듯.. J)로 시작한다. 이런 관습을 깨뜨린 사람에게 어떤 일이 일어났는지 잘은 모르지만, 별로 신경 쓰지 않아도 될 듯 하다. 커널 모듈을 작성하는 기본이 되는 다른 측면에서의 예로 Hello World류의 프로그램을 가지고 시작해보자.(어색한 번역...)

다음은 가장 간단한 모듈이다. 아직 컴파일하지 말자; 다음 장에서 모듈을 컴파일하는 것에 대해 다룰 것이다.

Example 2-1. hello-1.c

커널 모듈은 최소 두 개의 함수를 포함해야 한다: 모듈이 커널에 적재될 때 호출되는 시작(초기화) 함수인 init_module() 그리고 모듈이 해제되기 직전에(rmmod) 호출되는 종료(해제) 함수인 cleanup_module()이 바로 그것이다. 실제, 커널 2.3.13부터 이런 부분에 많은 변화가 있었다. 당신은 시작하거나 종료할 때 마음에 드는 것을 사용할 수 있으며, 이런 것들을 Section 2.3에서 배울 것이다. 사실 새로운 방식이 더 낫다. 그러나 많은 사람들이 여전히 시작과 끝에 init_module() 과 cleanup_module()함수를 사용한다.

전형적으로 init_module()함수는 커널에 어떤 헨들러를 등록하거나, 커널이 가지고 있는 함수의 코드를 대체한다. 일반적으로 특정한 작업을 수행한 후, 원래의 함수를 다시 호출한다.). cleanup_module()함수는 init_module()함수가 행한 것을 복귀시켜 모듈을 안전하게 해제(unload)할 수 있게 한다.

마지막으로 모든 커널 모듈은 linux/module.h를 포함해야 한다. linux/kernel.h는 printk()함수의 log level인 KERN_ALERT를 위해서만 여기서 필요하며 이런 내용은 printk()함수 소개에서 배울 것이다.

당신의 생각과 다르게 printk()는 사용자와 정보 교환을 위한 것은 아니다.(우리가 이런 목적으로 hello-1에서 printk()를 사용할 지라도) 이것은 커널에 기록(logging)하는 방식이며, 경고를 하거나 정보를 남기기 위해 사용된다. 각각의 printk()는 우선 순위를 가지고 사용되며, /which is the <1> and KERN_ALERT you see /이것은 <1> 혹은 KERN_ALERT 와 같은 형태로 사용된다. 8개의 우선순위가 있으며, 커널은 그에 상응하는 매크로를 가지고 있어 이해하기 어려운 번호를 사용할 필요가 없다. 이들은 linux/kernel.h에서 찾아볼 수 있다. 우선 순위를 정하지 않고 사용한다면 기본적인 우선순위인 DEFAULT_MESSAGE_LOGLEVEL이 사용될 것이다.

우선 순위 매크로를 읽기를 권한다. 헤더 파일은 각 우선 순위가 의미하는 바도 설명해 준다. 실제 <4>와 같은 번호는 쓰이지 않으며 대신 KERN_WARNNING과 같은 매크로를 사용한다.

만약 int console_loglevel보다 우선 순위가 낮으면, 해당 메시지는 당신의 현재 터미널에 보여질 것이다. syslogd와 klogd가 실행 중이라면 메지시가 콘솔로 출력여부와 관계 없이 /var/log/messages에 추가된다. printk()의 메시지가 로그 파일에만 남겨지지 않고 콘솔로 반드시 출력되도록 하기 위해 KERN_ALERT와 같이 높은 우선순위를 사용한다. 실제 모듈을 작성할 때 적절히 상황에 맞는 우선순위를 사용하기 원할 것이다.

커널 모듈은 재대로 작동하기 위해서 GCC의 특정한 옵션과 함께 컴파일 되야 한다. 정의된 특정한 심볼과 함께 컴파일 될 필요도 있다. 실행 파일을 컴파일하는지 커널 모듈을 컴파일하는지에 따라 커널 헤더 파일이 다르게 동작해야 하기 대문이다. GCC의 –D옵션을 사용하거나 #define 프리프로세서 명령을 사용해 심볼을 정의할 수 있다. 이 장에서 커널 모듈을 컴파일하기 위해 필요한 것들을 모두 다룬다.

• -c: 커널 모듈은 독립적으로 실행 가능한 파일이 아니며, insmod를 사용하여 실행 시간 중에 커널에 링크되는 오브젝트 파일 이다. 결론적으로 모듈은 -c옵션을 주고 컴파일 해야 한다.
  
  
• -O2: 커널은 인라인 함수를 주로 사용하기 때문에 모듈은 이 옵션 플래그를 사용해야 한다. 이 옵션을 사용하지 않은 경우 어떤 어셈블러 매크로는 함수 호출 시 정상적으로 작동하지 않을 것이다. insmod는 커널에서 원하는 함수를 찾지 못하고 결국 모듈의 적재는 실패할 것이다.
  
  
• -W -Wall: 프로그램에서의 실수는 당신의 시스템을 다운 시킬 수도 있다. 컴파일러 경고 기능은 항상 켜둬라, 이것은 모듈 컴파일 뿐 아니라 당신의 모든 컴파일 행위에 적용된다.
  
  
• -isystem /lib/modules/uname -r/build/include: 컴파일 대상이 되는 커널의 헤더를 사용해야만 한다. 기본적인 /usr/include/linux를 사용하는 것은 작동하지 않을 것이다.
  
  
• -DKERNEL:이 심볼을 정의 하는 것은 헤더 파일에 이 코드가 유저 프로세스로 동작하지 않고 커널 모드에서 작동한다는 사실을 알린다.
  
  
• -DMODULE: 이 심볼은 헤더 파일에 커널 모듈을 위한 올바른 정의를 하게 한다.
  
  

module.h를 포함 시킬 때 –W –Wall이 유발시키는 사용하지 않는 변수에 대한 경고를 GCC로 하여금 막기 위해, -I 옵션 대신 GCC의 -isystem옵션을 사용해야 한다. GCC-3.0하에서 –isystem을 사용함으로써 커널 헤더를 주의 깊게 다루어지고 경고는 절재 된다. -I옵션을 대신 사용한다면 (gcc 2.9x하에서 -isystem옵션을 사용하는 것도 ) 사용하지 않는 변수에 대한 경고가 출력될 것이다. 그렇다면 무시하면 된다.

hello-1.c 모듈 컴파일을 위한 Makefile을 살펴보자

Example 2-2. Makefile for a basic kernel module

연습으로 hello-1.c를 컴파일하고 insmod ./hello-1.o를 커널에 올려보자. 잘되는가? 커널에 적재된 모든 모듈은 /proc/modules에 리스트된다. 당신의 모듈이 커널의 일부가 됐는지 알아 보기 위해 그 파일을 출력해보자. 축하한다. 당신은 리눅스 커널코드의 작성자가 됐다. 즐거움은 잠시 미뤄두고 rmmod hello-1를 사용해 커널로부터 당신의 모듈을 제거 하자. 당신의 시스템 로그파일에 기록이 됐는지 보기 위해 /var/log/messages 파일을 살펴 보자.

독자를 위한 또 다른 예제가 있다. 앞서 언급한 init_module()함수의 리턴 값을 0 아닌 음수로 변경한 후 다시 컴파일 하고 로드해 보자. 어떤 일이 일어나는가?

여러분은 여러분의 init 와 cleanup 함수 이름을 바꿀 수 있다. 이후로 그들의 이름이 반드시 init_moduel(), cleanup_module()일 필요는 없다. 이는 module_init()와 module_exit()매크로에 의해 이뤄진다. 이 매크로는 linux/init.h에 저의 되있다. 선행되야 할 것은 매크로를 호출하기 전에 init와 cleanup함수라 정의 돼있어야 한다 것 뿐, 그렇지 않다면 컴파일 에러를 만날 것이다. 이런 테크닉의 예가 있다.

Example 2-3. hello-2.c

이제 우리는 두개의 실제 커널 모듈을 체험했다. 생산성을 높이기 위해 우리는 Makefile을 활용해야 한다. 다음은 앞 두 개의 모듈을 모두 컴파일 할 수 있는 개선된 Makefile 이다. 간결성, 규모면에서 최적화된 것이다. 다음을 이해할 수 없다면 GNU Makefile매뉴얼 혹은, makefile info페이지를 읽기 바란다.

Example 2-4. Makefile for both our modules

독자들을 위한 예로, 만약 같은 디렉토리에 hello-3.c 같은 모듈이 하나 더 있다면 그 모듈을 자동으로 컴파일 하기 위해 당신은 Makefile을 어떻게 수정할 것인가?

다음은 커널 2.2나 혹은 그 후 버전에서의 예다. init와 cleanup 함수의 정의에서의 변화를 주목하라. 내장된 드라이버에 대해 init함수가 수행되면, __init매크로는 init함수가 버려지고(-_-“) 메모리가 반환된다. 그러나 모듈은 적재 불가능하다. 언제 init함수가 호출되는 가를 생각한다면 이것은 완전히 타당하다고 느낄 것이다.

init함수 자체에 대한 것이라기 보다는 init변수에 대해 작용하는 __init와 유사한 매크로인 __initdata라는 것도 있다. __exit매크로는 모듈이 커널로 빌트인(모듈로 컴파일 하는 것이 아닌 커널 일부로 컴파일 하는 것)될 때, 함수의 호출을 생략하며 __exit처럼 적재 가능한 모듈에 어떤 영향도 미치지 않는다. 마찬가지로 언제 cleanup함수가 작동하는 고려한다면 이해될 것이다. 내장된 드라이버는 cleanup함수가 필요 없다. 반면에 적재 가능한 모듈은 필요하다.

이 매크로들은 linux/init.h에 정의 돼 있고 사용된 커널 메모리를 해제하는데 사용된다. 부팅 후 ‘Freeing unused kernel memory: 236k freed’ 와 같은 메시지를 볼 때 , 커널이 메모리를 해제하는 것이다.

Example 2-5. hello-3.c

리눅스 2.2 커널을 위한 드라이버 모듈에서 __initfunction() 같은 함수를 보았을 것이다. 이 메크로는 __init와 같은 동작을 한다. 그러나 __init에 비해 매우 적게 사용된다. 그저, 커널에서 당신이 보았을 수도 있기에 언급한 것이다. 2.4.18 버전의 커널에 __initfunction()은 38군데에서 보이고, 2.4.20에서는 37군데에서만 보인다. 그러나 당신의 코드에서는 사용하지 말 것을 권한다.

커널 버전 2.4나 그 후 버전을 사용한다면, 앞서 언급한 모듈 예를 적재할 때 다음과 같은 메시지를 보게 될 것이다.

# insmod hello-3.o
Warning: loading hello-3.o will taint the kernel: no license
  See http://www.tux.org/lkml/#export-tainted for information about tainted modules
Hello, world 3
Module hello-3 loaded, with warnings

2.4버전 이후의 커널에서 GPL 라이센스 코드를 식별하기 위한 메커니즘이 고안돼서, 오픈 소스가 아닌 경우 사용자들에게 경고를 할 수 있게 돼있다. 이는 다음 코드에서 제시된 MODULE_LICENSE() 매크로에 의해 충족된다. GPL라이센스로 설정함으로써 경고가 출력되는 것을 방지 할 수 있다. 이런 라이센스 메커니즘은 linux/module.h에 정의되있고 문서화 되어 있다.

비슷하게 MOUDLE_DESCRIPTION() 은 모듈이 무엇을 하는가를 , MOUDLE_AUTHOR()은 모듈의 저자를 MODULE_SUPPORTED_DEVICE()는 어떤 타입의 장치를 모듈이 지원하는 가를 알려준다.

이런 매크로들은 linux/module.h에 정의되있고 커널 자체에서는 사용되지 않는다. 이것들은 문화를 간단히 하며, objdump와 같은 툴을 이용해 볼 수 있다. 독자들의 연습을 위해 linux/drivers에서 어떻게 모듈 저자들이 모듈을 문서화 하기 위해 이 매크로들을 사용했는가 찾아 보길 바란다.

Example 2-6. hello-4.c

모듈은 커맨드라인 인자를 받을 수 있다. 기존에 사용하던 것처럼 argc/argv를 가지고 할 수는 없다.

인자를 당신의 모듈로 넘기기 위해서는 커맨드라인 인자의 값을 저장할 변수를 전역으로 선언한 후 메커니즘을 활성화 시키기 위해 MODULE_PARAM()매크로를 사용한다. 실행 시간에 insmod는 주어진 인자로 변수를 채울 것이다. 변수의 선언과 매크로들은 명확성을 위해 모듈 서두에 위치해야 한다. 다음의 예는 어눌한 내 설명을 명백히 해준다.(내 번역도 ^^)

MODULE_PARAM() 매크로는 2개의 인자를 받는다 변수의 이름과 타입 지원하는 타입은 1byte인”b”, short int인 “h”, integer인 “i”, long인 “l”, string인 “s” 등 이다. 문자열(strings – string과 strings와 구분)은 “char *”로 해야 하며, insmod는 그 문자열(strings)을 위한 메모리를 할당한다. 늘 변수를 초기화하는 습관을 갖길 권한다. 이것은 커널 코드이다. 당신은 반드시 방어적으로 프로그래밍 해야 한다. 다음은 예제다. 배열 역시 지원된다. MODULE_PARM에 선행되는 integer 값은 배열의 최대 길이를 알려준다. ‘-‘에 의해 분리된 두 번호는 최대 최소 값을 알려 준다. 예를 들어 최소값 2과 최대값 4를 갖는 short형의 배열은 다음과 같이 선언될 수 있다. 어떤 IO포트 혹은 IO 메모리가 사용되는지와 같이 모듈의 변수 값은 디폴트 값으로 세팅 되는 것이 좋다. 만약 변수가 기본값을 갖는다면 자동인식(차후에 설명이 나옴)를 수행 할 수 있다. 그렇지 않다면 현재의 값을 유지한다. 이것은 앞으로도 명확하다. 지금은 모듈로 인자를 넘기는 것만을 예로 들겠다.

Example 2-7. hello-5.c

Supercalifragilisticexpialidocious(저자가 쓴 암호 중 하나... -_-)

때로는 커널 모듈을 여러 개의 소스파일로 나누는 것이 좋을 때가 있다. 이런 경우 다음과 같은 사항이 필요하다.

1. 하나의 파일을 제외하고 모든 소스 파일에 #define NO_VERSION 이 필요하다. module.h는 일반적으로 kernel_version, 모듈이 컴파일되는 커널의 전역 변수를 포함하기 때문에 이것은 중요하다. 만약 version.h가 필요하다면 그것을 포함시켜야 한다. 왜냐하면 NO_VERSION를 가진 module.h 은 이것을 해주지 않는다.
   
   
2. 일반적으로 모든 소스 파일을 컴파일 해야 한다.
   
   
3. 모든 오브젝트 파일을 하나로 컴파일 해야 한다. X86환경에서는 ld -m elf_i386 -r -o <module name.o> <1st src file.o> <2nd src file.o>를 사용한다.
   
   

다음은 앞서 언급한 것에 대한 예제다.

Example 2-8. start.c 다음 파일

Example 2-9. stop.c

마지막으로 Makefile

Example 2-10. Makefile for a multi-filed module

일반적으로 프로그램은 main()함수에서 시작한다, 명령어들의 집합을 실행하고 명령어들의 완료 시 종료된다. 커널 모듈은 약간 다르게 작동한다. 모듈은 항상 init_module()함수, 혹은 당신이 module_init()라는 함수에 지정한 곳에서 시작한다. 이것이 모듈의 진입 함수다(entry function); 모듈이 필요해질 때 이 함수들은 커널에게 그 모듈의 기능은 무엇이며 어떻게 설정되는 가를 알려 준다. 이런 설정이 이뤄지면 모듈을 시작하는 함수는 리턴하고 모듈이 제공하는 코드를 가지고 커널이 무엇인가를 하려할 때까지 모듈은 아무런 일을 하지 않는다.

모든 모듈은 cleanup_module(), 혹은 module_exit()에 지정되 있는 함수를 호출할 때 종료된다. 이것이 모듈의 종료 함수(exit function)가 된다. 이 함수는 진입 함수가 무엇을 하던 종료 시킨다. 진입 함수에 등록되 있는 기능을 해제한다..

모든 모듈은 진입함수와 종료함수를 갖는다. 하나 이상의 진입함수와 종료함수를 지정하는 방법이 있기에, `진입함수(entry function)'와 `종료함수(exit function)'라는 단어를 사용하겠다. 그러나 내가 간단히 init_module() 그리고 cleanup_module()이라 하더라도, 독자들은 내가 무엇을 의미하는지 알 것이라 생각하겠다.

프로그래머들은 자신들이 정의한 함수만을 사용하는 것은 아니다. 대표적인 예가 printf()다. 프로그래머들은 표준 C라이브러리에서 제공하는 이런 라이브러리 함수들을 사용한다. 실제 이런 함수들의 정의는 링킹 스테이지(linking stage)가 될 때까지 프로그램에 들어가지 않는다. 그리고 이런 것은 코드가 사용 가능하다는 것을 보장해주고 그 위치에 명령어(instruction)를 위치 시켜준다.

여기서도 커널 모듈은 다는 양상을 띤다. 전술한 예제에서, 우리는 printk()라는 함수를 사용했다 그리고 그것은 표준 라이브러리 함수가 아님을 알 것이다. 모듈은 insmod에 의해 해석되지는 심볼을 갖는 오브젝트 파일이기 때문이다. 심볼의 정의는 커널 자체에 있다. 당신이 사용 가능한 유일한 외부 함수는 커널에 의해 제공되는 것들에 한정되어진다. 어떤 심볼(역주-모듈에서 직접 정의하지 않고 사용할 수 있는 함수)들이 사용가능한지 궁금하다면 /proc/ksyms을 살펴봐라.

라이브러리 함수와 시스템 콜의 차이점을 명심하자. 라이브러리 함수들은 상위 레벨에 있으면서, 완벽하게 유저 레벨에서 실행되며, 프로그래머가 실제 작업을 하는데 편의를 제공해준다. 시스템 콜은 커널에 의해 제공되며 사용자의 행위에 따라 커널 레벨에서 실행된다. 라이브러리 함수인 printf()는 가장 일반적인 출력함수처럼 보인다. 그러나 그것이 실제로 하는 일은 데이터를 스트링으로 포맷하고 스트링 데이터를 로우레벨 시스템 콜인 write()를 이용하는 것이다, 그리고 그것은 그 데이터를 표준 출력으로 내보낸다.

Printf()가 무엇으로 구성되있는 보고 싶은가? 그것을 알아보는 것은 굉장히 쉽다. 다음의 프로그램을 컴파일 해보자. gcc -Wall -o hello hello.c. strace hello을 실행해보자. 놀랐는가? 당신이 보는 각각의 행이 시스템 콜에 해당된다. strace1는 어떤 시스템콜로 프로그램이 구성됬는가, 어떤 아규먼트가 넘겨지는가, 무엇을 리턴하는가를 보여주는 간단한 프로그램이다. 이 프로그램은 프로그램이 어떤 파일에 접근하는가와 같은 것들을 설명하는데 매우 중요한 도구다. 끝 부분에 write(1, "hello", 5hello)라는 부분을 볼수 있을 것이다. 이것이 printf()의 정체다. 대부분의 사람들은 파일 입출력에 fopen(), fputs(), fclose()와 같은 라이브러리 함수를 사용하기 때문에, write()에 익숙하지 않을 것이다. 만약 당신도 그렇다면 , man 2 write을 보라. 매뉴얼 페이지의 2번째 섹션은 kill(), read()와 같은 시스템 콜에 할당되있다. 3번째 섹션은 독자들이 익숙한 cosh(), random() 등의 라이브러리 함수에 할당 되어 있다.

당신도 커널의 시스템 콜을 대체하기 위해 모듀을 쓸 것이다.(우리가 간단히 할것이다) 크래커들이 백도어용으로 이런 종류의 것들을 사용한다. 누군가 당신의 시스템에 있는 파일을 지우려 시도할 때마다 당신은 모듈을 이용해서 “간지러 장난 치지마”(역주Tee hee, that tickles! 의역)라는 식의 온화한 대응을 할 수 있을 것이다.

커널은 비디오 카드, 하드 드라이브, 심지어 메모리까지 모든 리소스에 접근한다. 프로그램은 종종 같은 리소스에 대해 경쟁한다. 내가 이 문서를 저장할 때, updatedb가 위치에대한 데이터 베이스를 갱신하기 시작한다. 나의 vim 세션과 updatedb가 같은 하드 드라브를 동시에 사용하는 것이다. 커널은 이런 것들을 순서대로 유지할 필요가 있으며, 사용자가 그들이 원하는 자원에 직접 접근하도록 권한을 주어서는 안 된다. 이런 이유로 CPU는 다른 방식으로 작동한다. 각 모드는 당신이 시스템에 하고자 하는 일에 대한 서로 다른 레벨의 권한을 준다. 인텔의 30386 아키텍쳐는 4개의 모드를 가지고 있다. 유닉스는 모든 것이 가능한 관리자 모드로 알려진 0 모드(최상위 모드 – ring의 단어선택이... -_-)와 유저 모드로 불리는 최하위 모드, 두 가지만을 사용한다.

라이브러리 함수와 시스템 콜에 대한 논의를 상기하자. 당신은 전형적으로 사용자유저모드에서 라이브러리 함수를 사용한다. 라이브러리 함수는 하나 혹은 그 이상의 시스템 콜을 호출한다. 그리고 이런 시스템 콜은 라이브러리 함수처럼 행동한다. 그런 관리자 모드에서는 커널의 일부이기 때문에 그렇게 행동한다. 시스템콜이 그 작업을 완료하면 복귀(return)하고 유저보드로 복귀한다.

당신이 C프로그램을 작성할 때, 당신은 코드를 보는 사람들의 가독성을 위해 변수이름을 사용했을 것이다. 규모가 큰 프로그램의 일부를 작성하고 있을 때, 당신의 전역변수가 같이 일하는 사람의 전역변수의 이름과 같다면 변수이름으로 인해 문제가 될 수 있다. 서로 구분할 만큼 의미 있는 이름을 갖지 못한 전역변수가 많이 존재한다면 이름공간이 오염될 것이다. 대규모 프로젝트에서 사용 보류된 이름에 대해 이런 노력은 반드시 있어야 하며, 심볼과 변수의 유니크한 명명 법에 대한 계획이 필요하다.

커널 코드를 작성할 때 그것이 아무리 작은 모듈이라도 커널 전체에 링크되기 때문에 이것은 분명 문제가 된다. 이것을 해결하는 가장 좋은 방법은 변수를 정적 변수로 선언하고, 잘 정의된 접두어를 당신의 심볼에 사용하는 것이다. 관습적으로 커널의 접두어는 소문자다. 모든 것을 정적으로 선언하기 원치 않는다, symbol table을 선언하고 그것을 커널에 등록시키는 방법을 쓴다. 차후에 이것을 하게 될 것이다.

/proc/ksyms는 커널이 알고 있는 모든 심볼을 가지고 있고, 그 심볼은 커널 코드 스페이스에서 공유되기 때문에, 당신의 모듈이 접근/사용할 수 있다.

메모리 관리는 매우 복잡한 주제다. `Understanding The Linux Kernel의 상당 부분이 메모리 관리에 중점을 둔다. 우리는 비록 메모리 관리에 전문가는 아니지만 실제 모듈을 작성하는데 고려해야 할 두 가지 사실에 대해 알 필요는 있다.

실제로 세그멘트 폴트가 무엇을 의미하는지 생각해보지 않았다면 포인터가 실제 메모리 위치를 지시하고 있지 않다는 것을 듣게 되면 놀랄 것이다. 어쨌든 어느 포인터도 그렇지 않다. 프로세스가 생성될 때, 커널은 실제 메모리의 일부를 할당해, (컴퓨터 학자나 알법한 것들) 프로세스가 사용하는 실행코드, 변수, 스택, 힙 등으로 사용하도록 프로세스에게 넘긴다. 이 메모리는 $0$에서 시작해 프로세스가 필요한 만큼 확장된다. 서로 다른 두 프로세스의 메모리 영역은 겹치지 않기 때문에 0xbffff978에 접근하는 모든 프로세스는 실제 물리적 메모리의 서로 다른 지점에 접근할 것이다. 프로세스들은 특정 프로세스에게 할당된 메모리 영역으로의 오프셋의 한 종류를 지시하는 0xbffff978로 이름 지어진 인덱스에 접근하려 할 것이다. 이후에 다루게 될 방법이 있음에도 불구하고, 우리의 Hello, World와 같은 대부분의 경우 다른 프로세스의 영역에 접근할 수 없다.

커널 역시 자신만의 메모리 영역이 있다. 모듈은 동적으로 커널에 적재 되거나 제거될 수 있는 코드기 때문에, 모듈은 자신만의 커널 코드 영역을 가지기 보다는 커널 코드 영역을 공유한다. 즉, 반 독립적 객체에 상반되는 개념이다. (as opposed to a semi-autonomous object 의 의역) 그러므로 우리의 세그먼트 폴트는 커널의 세그먼트 폴트가 된다. off-by-one 에러 때문에 데이터를 겹쳐 쓰기 시작한다면, 커널 코드를 망가트릴 것이다. 이건 생각보다 심각하므로 주의를 기울여야 한다. ( off-by-one error : n=0에서 시작할 것을 n=1에서 시작함으로 해서 일어나는 류의 에러를 의미함) 위에서 언급한 사실들은 모놀리틱 커널을 사용하는 모든 오퍼레이팅 시스템에서 적용된다는 것을 지적하고 싶다. 자기 자신만의 코드 영역을 갖는 마이크로 커널이라는 것도 있다. GNU Hurd와 QNX Neutrino가 마이크로 커널의 예다.

모듈의 한 종류가 장치 드라이버이며, 그들은 TV카드나 시리얼 포트 같은 하드웨어의 기능을 제공한다. 유닉스에서 하나의 하드웨어는 하드웨어와 의사 통신하는 수단을 제공하는 named device 파일(/dev/ 아래 위치한다.)로 보여진다. 디바이스 드라이버는 유저 프로그램을 대신해, 의사 소통 수단을 제공한다. es1370 사운드카드 드라이버는 Ensoniq IS1370 사운드 카드에 연결하기 위해 /dev/sound device에 연결한다. mp3blaster와 같은 유저 스페이스 프로그램은 어떤 종류의 사운드 카드가 설치됐는지 모른 체 /dev/sound라는 장치를 사용할 수 있다.

디바이스 파일을 살펴보자. 다음은 프라이머리 마스터 IDE하드 드라이버의 첫 세 개 파티션을 나타내는 디바이스 파일이다.

# ls -l /dev/hda[1-3]
brw-rw----  1 root  disk  3, 1 Jul  5  2000 /dev/hda1
brw-rw----  1 root  disk  3, 2 Jul  5  2000 /dev/hda2
brw-rw----  1 root  disk  3, 3 Jul  5  2000 /dev/hda3

콤마에 의해 구분된 번호의 열을 주시하자 첫 번째 번호를 장치 주 번호라 부르며 두 번째 번호는 부 번호라 부른다. 주 번호는 드라이버가 어떤 하드웨어에 엑세스하는지 알려준다. 각 드라이버는 유일한 주 번호를 할당 받으며, 동일한 주 번호를 갖는 모든 디바이스 파일은 같은 드라이버에 의해 컨트롤 된다. 위의 주 번호가 모두 3인 것은, 그들이 같은 드라이버에 의해 콘트롤 되기 때문이다.

부 번호는 드라이버가 자신이 컨트롤하는 하드웨어를 구분하기 위해 사용된다. 위의 예로 돌아가 보자, 세 개의 장치들이 같은 드라이버에 의해 운영될지라도 서로 다른 고유의 부 번호를 갖는데, 이는 드라이버가 그들(하드 디스크 파티션들)을 서로 다른 하드웨어로 인식하기 때문이다.

디바이스는 캐릭터 디바이스와 블록 디바이스의 두 타입으로 나뉜다. 블록 디바이스는 버퍼를 가지고 있어, 어떤 순서로 응답하는 것이 가장 좋은 것인가 선택할 수 있다는 것이 차이점이다. 이점은 물리적으로 떨어져있는 섹터보다 가까이 있는 섹터에 읽기/쓰기를 하는 것이 빠르다는 점에서 저장 장치에 있어 중요하다. 또 다른 차이점은 블록 디바이스만이 입출력 시 블록 단위로 접근할 수 있다는 점이다(블록의 크기는 장치에 따라 다르다). 반면에 캐릭터 디바이스는 몇 바이트 되지 않는 크기만을 허용한다. 대부분의 장치는 캐릭터 디바이스이다. 왜냐하면 장치들 대부분이 이런 종류의 버퍼일을 필요로 하지 않고 고정된 블록 크기에 대해 작동하지 않기 때문이다. ls –l의 결과에서 첫 번째 문자를 살펴 봄으로써 디바이스가 블록 디바이스인지 캐릭터 디바이스인지 구분할 수 있다. 만인 첫 문자가 ‘b’이면 블록디바이스고, ‘c’이면 캐릭터 디바이스이다. 다음은 캐릭터 디바이스의 예다(시리얼 포트).

crw-rw----  1 root  dial 4, 64 Feb 18 23:34 /dev/ttyS0
crw-r-----  1 root  dial 4, 65 Nov 17 10:26 /dev/ttyS1
crw-rw----  1 root  dial 4, 66 Jul  5  2000 /dev/ttyS2
crw-rw----  1 root  dial 4, 67 Jul  5  2000 /dev/ttyS3

만일 어떤 주 번호가 할당됐는가 알기를 원한다면, /usr/src/linux/Documentation/devices.txt 파일을 참고하기 바란다.

시스템이 설치될 때, 이런 디바이스 파일들은 mknod에 의해 생성된다. 주번호/부번호 12, 2의 ‘coffee’라는 새로운 캐릭터 디바이스를 생성하고자 한다면, 단순히 mknod /dev/coffee c 12 2만 실행시키면 된다. 디바이스 파일을 /dev/에 넣을 필요는 없다. 단순히 관습일 뿐이다. 리누즈가 그의 디바이스 파일을 /dev/에 넣었기 때문에 당신도 그렇게 하는 것이 낫을 것이다. 그러나 테스트 목적으로 디바이스 파일을 생성한다면, 커널 모듈을 컴파일한 작업 디렉토리에 디바이스 파일을 넣어도 무방하다. 디바이스 드라이버 작성이 완료됐을 때 올바른 위치에만 넣으면 된다.

나는 이전에 언급했던 것들과 상충되는 몇 가지 지적을 하기를 좋아 한다. 하지만 그것들은 단지 몇몇 경우에만 국한된다. 디바이스 파일이 액세스될 때 커널은 장치 주 번호를 어떤 드라이버를 이용해 그 액세스를 처리할 것인가를 결정하기 위해 사용한다. 이 이야기는 커널은 장치 부 번호를 사용할 필요가 없고, 심지어 몰라도 된다는 말이다. 장치 부 번호에 관심을 갖는 것은 드라이버 자체 뿐이다. 동일한 종류의 하드웨어 중에 어떤 장치인가를 구분하기 위해서만 장치 부 번호는 사용된다.

그런데 내가 ‘하드웨어’라고 했을 때, 난 당신의 손에 있는 PCI카드 이상의 좀더 추상적인 것을 의미하는 것이다. 다음의 디바이스 파일을 보자.

% ls -l /dev/fd0 /dev/fd0u1680
brwxrwxrwx   1 root  floppy   2,  0 Jul  5  2000 /dev/fd0
brw-rw----   1 root  floppy   2, 44 Jul  5  2000 /dev/fd0u1680

이제 두 개의 디바이스 파일을 보고 그들이 블록 디바이스라는 것과 동일한 드라이버에 의해 처리된다는 것을 즉시 알 수 있을 것이다. 두 개의 디바이스 파일은 당신의 플로피 드라이브를 나타낸다는 것을 알 것이다. 그런데 당신은 하나의 플로피 드라이버만을 가지고 있지 않은가. 왜 두 개인가? 하난 1.44MB의 플로피 드라이브를 나타낸다. 다른 하나는 흔히 말하는 ‘superformatted’ 드라이브에 해당되는 1.68MB의 동일한 저장 장치다. 표준 포맷 플로피 보다 많은 양의 데이터를 저장하는 것이다. 이것이 동일한 실제 하드웨어에 서로 다른 장치 부 번호를 갖는 경우다. 우리의 논의에서 ‘하드웨어’라고 하는 단어가 상당히 추상적이라는 것을 알기 바란다.

file_operations 구조체는 linux/fs.h에 정의되 있으며 장치들에 대해 다양한 작동을 하는 드라이버에 의해 정의된 함수들을 가지고 있다. 구조체의 각 필드는 요구되는 작동을 하기 위해 드라이버에 의해 정의된 함수들의 주소에 대응된다.

예를 들어, 모든 문자 장치 드라이버는 장치로부터 데이터를 읽어 오는 함수를 정의 할 필요가 있다. file_operations 구조체는 그런 기능을 하는 함수 모듈의 주소를 가지고 있는 것이다. 커널 2.4.2에서 그 정의는 다음과 같다.

어떤 동작들은 드라이버에 의해 구현되지 않는다. 예로 비디오카드를 다루는 드라이버는 디렉토리 구조체에서 데이터를 읽어올 필요는 없다. 이 경우 file_operations구조체의 해당 필드는 NULL로 세팅된다.

gcc의 확장 버전은 이 구조체에 인자 할당을 좀더 편하게 해준다. 최근 만들어진 드라이버들에서 이런 것들을 볼 수 있다, 아마도 (사용 방법 때문에) 놀라움을 줄 수도 있다. 다음은 이런 새로운 할당 방식을 보여준다.

그러나 C99방식의 구조체 멤버 할당방식도 여전히 존재하며 GNU확장 버전을 사용함에 오히려 이 방식이 선호되고 있다. 내가 현재 사용하고 있는 gcc 2.95버전은 C99 문법의 새로운 부분을 지원하고 있다. 누군가 당신의 드라이버를 포팅하기 원하는 경우 당신은 이 문법을 사용해야 할 것이다. 이 경우 두 종류의 신텍스가 공존할 수 있다.

의미는 명확하다 그리고 당신이 할당하지 않은 구조체의 멤버는 gcc에 의해 NULL로 초기화된다는 사실을 기억하자. file_operations 구조체의 포인터는 일반적으로 fops라는 이름을 갖는다.

각각의 장치들은 file구조체에 의해 커널 내부에 보여진다. 그리고 그것은 linux/fs.h에 정의 되있다. 구조체는 커널 내부에 존재하며 사용자 공간의 프로그램에서는 절대 보이지 않는다는 것을 명심하자. 구조체와 같지 않다. FILE구조체는 glibc에 정의되 있고 커널영역에는 절대 보이지 않는다. 이름 때문에 잘못 이해되기도 한다. 그것은 열린 파일을 의미하지 디스크상의 inode구조체에 이해 지시되는 파일을 의미하는 것은 아니다.

file구조체의 포인터는 일반적으로filp라는 이름을 갖는다. struct file file와 혼돈하지 말자(완전 통밥-_-)

file구조체의 정의를 살펴보자. 대부분의 멤버들이 dentry구조체처럼 디바이스 드라이버에서 사용되지 않는다. 또한 그런 부분은 무시해도 좋다. 디바이스 드라이버는 file구조체를 직접적으로 채우지 않고 어디선가 생성한 파일 구조체의 내용을 단지 이용하기만 할 뿐이다.

앞서 논의한 것처럼 문자장치는 보통 dev1 에 있는 디바이스 파일을 통해 접근된다. 주장치 번호는 어느 드라이버가 어는 디바이스 파일을 사용하는가 알려준다. 부 장치번호는 드라이버가 하나 이상의 장치를 작동시킬 때, 어떤 장치가 가동되는가를 구분하기 위해 드라이버 내부에서 사용된다.

시스템에 드라이버를 추가한다는 것은 커널에 그것을 등록시키는 것을 의미한다. 모듈이 초기화되는 동안 주장치 번호를 부여한다는 것과도 같은 의미다. linux/fs.h에 정의된 register_chrdev()함수를 사용함으로써 이런 작업을 수행한다.

unsigned int major는 요청할 주장치 번호이고, const char *name은 /proc/devices에 나오는 장치 이름이고 struct file_operations *fops는 드라이버를 위한 file_operations table의 포인터다. 음수를 리턴 할 경우 장치 드라이버 등록에 실패한 것이다. 부장치 번호를 register_chrdev()에 넘기지 않는다는 것에 유의하자. 커널은 부장치 번호에 전혀 신경쓰지 않기 때문이다. 우리의 드라이버만 그 번호를 사용한다.

이제 어떻게 이미 사용중인 번호를 가로채지 않고 주장치 번호를 얻어오느냐는 생각이 든다. 가장 쉬운 방법은 Documentation/devices.txt를 보고 사용하지 않는 것을 선택하는 것이다. 그러나 이 번호가 나중에 사용될 수 있으므로 좋은 방법은 아니다. 해결책은 커널에게 동적으로 주장치 번호를 할당해 줄 것을 요청하는 것이다.

register_chrdev()에 주장치 번호 0으로 넘기면, 동적으로 할당된 주장치 번호를 리턴 해준다. 주장치 번호를 알 수 없기 때문에 미리 디바이스 파일을 만들 수 없다는 단점이 있다. 몇 가지 해결 책이 있다. 우선, 드라이버가 자신에게 할당된 주장치 번호를 출력하고 수작업으로 그 장치 파일을 만드는 것이다. 다음으로, /proc/devices에 새로 등록된 장치가 있을 것이다. 우리는 직접 디바이스 파일을 만들던지 혹은 파일을 읽어 들여 디바이스 파일을 만드는 쉘 스크립트 만들면 된다. 세 번째로 장치 드라이버를 등록한 후mknod를 이용해 디바이스 파일을 만들고 cleanup_module()을 호출한 후 rm으로 삭제하는 것이다.

root가 그러고 싶다고 해서 커널 모듈을 rmmod하게 할 수는 없다. 프로세스에 의해 장치 파일을 열고 모듈을 제거한 후, 장치 파일의 사용시도는 read/write등 올바른 함수가 사용하던 메모리위치를 다른 것으로 하여금 사용하게 할 것이다. 만일 운이 좋다면 그곳에 아무런 코드도 로드되지 않을 것이고 에러 메시지를 받을 것이다. 우리가 운이 없다면 같은 위치로 다른 커널 모듈이 올라올 것이고 그것은 커널 내의 다른 함수의 중간 어딘가로 실행위치를 바꿔 버릴 것이다. 결과는 예상할 수 없으며 매우 부정적이다.

일반적으로 우리가 무엇인가 허가 하고 싶지 않다면 그 일을 처리하는 함수에서 에러코드(음수)를 리턴하도록 한다. void 타입이기 때문에 cleanup_module()에서는 이것이 불가능 하다. 그러나 얼마나 많은 프로세스가 그 모듈을 이용하고 있는지 추적하는 카운터가 있다. /proc/modules파일의 세 번째 필드의 값이 바로 이것이다. 이 번호가 0이 아니라면, rmmod는 실패한다. linux/module.c에 정의 되있는 sys_delete_module()에 의해 그 수가 체크되고 있으므로 cleanup_module()에서 카운트 할 필요가 없다. 직접적으로 카운터를 사용하지 말자, linux/modules.h에 정의된 매크로가 있다. 그것은 이 카운터를 증가시키거나 감소시키는 일을 한다.

• MOD_INC_USE_COUNT: 카운터를 증가시킨다.
• MOD_DEC_USE_COUNT: 카운터를 감소시킨다.
• MOD_IN_USE: 카운터를 보여준다.
  
  

카운터를 정확하기 유지시키는 것이 중요하다. 만약 정확한 카운터의 수를 잃어 버린다면, 모듈을 해제(unload)하는 것은 불가능하다. 부팅을 다시 하자. 모듈 개발을 하는 동안 언젠가는 닥칠 일이다.

다음의 코드는chardev라는 이름의 문자 드라이버를 만드는 간단한 예제다. 장치파일의 내용을 화면에 출력 (혹은 다른 프로그램을 이용해 열어 볼 수 있다)할 수 있다. 그러면 드라이버는 파일이 읽혀진 횟수를 파일에 기록한다. echo "hi" > /dev/hello와 같이 파일에 기록하는 것을 지원하지 않는다. 그러나 이런 시도를 감지해 사용자에게 쓰기 기능을 지원하지 않는 다는 것을 알려 준다. 우리가 읽어 버퍼에 기록하는 데이터를 가지고 우리가 하는 일을 볼 수 없다고 걱정하지 마라; 우리는 그것을 가지고 많은 일을 하지 않는다. 단지 데이터를 읽어서 그 데이터를 받았다는 메시지만 출력한다.

Example 4-1. chardev.c

커널과 프로세스 사이의 주요한 인터페이스인 시스템 콜은 일반적으로 버전을 일치시켜 사용한다. 새 버전의 시스템 콜이 추가되더라도 구 버전의 시스템 콜은 여전히 동작한다. 이것은 구 버전과의 공존을 위해 필요하다. –새 버전의 커널은 일반적인 프로세스를 중지시키려 하지 않는다. 대부분의 경우, 장치 파일은 그대로 남아있다. On the other hand반면에 , 커널 내부의 인터페이스는 버전마다 바뀐다.

리눅스 커널은 안정버전과 (n.$<$짝수$>$.m) 개발버전으로 (n.$<$홀수$>$.m) 나뉜다. 개발 버전은 다음 버전에서 다시 구현해야 한다거나 오류로 취급될 수도 있는 것을 내포한 모든 참신한 아이디어를 포함하고 있다. 결과적으로, 이런 개발버전의 인터페이스는 신뢰할 수 없다 (내가 이 글에서 그것들을 다루지 않는 이유이기도 하다. 그것은 고된 일이고 바뀌기도 빨리 바뀐다.). 반면에 안정버전에서, 버그 수정 여부와 관계없이 같은 인터페이스를 기대할 수 있다.

서로 다른 버전의 커널에는 다른 차이점들이 있다. 만일 여러 버전의 커널을 지원하려 한다면, 조건 지향적인 코드 컴파일 방식이 필요함을 알게 될 것이다.. LINUX_VERSION_CODE 와 KERNEL_VERSION를 비교하는 방법. 커널의 a.b.c버전에서, 매크로의 값은 이다. 커널2.0.35이전 에는 이 매크로가 없다는 것을 알아두자. 구식 커널을 지원하는 모듈을 작성하고자 한다면, 다음과 같이 정의 해야 한다.

Example 4-2. some title

물론 이런 매크로가 있기 때문에, 당신은 매크로의 존재여부를 테스트하기 위해 커널 버전을 테스트 하는 것보다 #ifndef KERNEL_ VERSION 을 사용하는 것이 좋을 것이다.

리눅스에는 커널과 커널 모듈이 프로세스로 정보를 보내는 추가적인 방법이 있다. /proc파일 시스템이 그것이다. 원래 이것은 프로세스에 관한 정보에 쉽게 접근하도록 설계된 것이다(이름을 보라.). 모듈의 리스트를 가지고 있는 /proc/modules, 그리고 메모리 사용량을 보여주는 /proc/meminfo등과 같이 커널이 관심을 갖는 것들에 상용된다.

/proc파일 시스템을 사용하는 방법은 디바이스 드라이버를 이용하는 방법과 매우 유사하다. 여러분은 함수의 핸들러 포인터를 포함해 /proc파일에 필요한 모든 정보를 가지고 구조체를 생성한다.( 우리의 경우 한가지 정보, 누군가 /proc 파일로부터 무엇인가 읽으려 시도할 때 그것이 호출된다.). 그런 후 커널에 init_module()이 그 구조체를 커널에 등록하고 cleanup_module이 등록을 해제한다.

우리가 우리의 파일이 이용할 inode 번호를 결정하기를 원하지 않고 커널이 결정하게 해서 시스템 다운을 방지하기 원하기 때문에 우리는 proc_register_dynamic()1함수를 사용한다. 일반적인 파일은 메모리에 존재하기보다는 디스크에 존재한다.(그것이 /proc이다.), 또한 그런 경우 파일의 인덱스 노드(index-node, inode는 약어다)가 위치한 디스크를 inode번호가 지시한다. inode구조체는 파일에 대한 정보를 담고 있다, 예를 들어 파일의 퍼미션, 디스크 어디서 파일의 데이터를 찾을 수 있는가 등등.

파일이 열리거나 닫힐 때 우리가 호출하지 않았기 때문에 , 모듈 내부에서 MOD_INC_USE_COUNT와 MOD_DEC_USE_COUNT에 접근할 방법이 없다. 또한 파일이 열린 상태에서 모듈이 제거될 때 생기는 문제를 피할 방법이 없다. 다음 장에서 우리는 더 복잡한 구현을 본다, 그러나 그것은 /proc파일을 다루는데 있어 더 유연한 방법을 제시해줄 것이다. 그리고 그것은 문제에 봉착하지 않게 해주기도 한다.

Example 5-1. procfs.c

지금까지 우리는 커널 모듈로부터 출력을 얻는 두 가지 방법을 알아 보았다. 우리는 장치 드라이버와 mknod를 등록하거나 /proc 파일을 생성할 수 있다. 이것은 커널 모듈로 하여금 우리에게 무엇인가를 전달할 수 있도록 해준다. 그 반대의 경우가 불가능하다는 것이 문제가 된다. 우선 커널 모듈에 데이터를 입력하는 것은 /proc 파일에 데이터를 쓰는 방법을 택한다.

/proc파일 시스템은 커널이 프로세스의 상태를 보고할 수 있도록 한 것이기 때문에 , 입력에 대한 특별한 배려는 없다. proc_dir_entry 구조체에는 출력 함수와 같은 방식의 입력 함수에 대한 포인터가 없다. /proc파일에 쓰기를 하는 대신, 표준 파일 시스템 메커니즘을 사용할 필요가 있다. 리눅스에는 파일 시스템 등록을 위한 표준 메커니즘이 있다. 모든 파일 시스템은 inode와 file operation을 다루기 위한 고유한 함수를 가지고 있어야 하기 때문에 이 모든 함수의 포인터를 가지고 있는 inode_operations 라는 구조체가 있으며, 그리고 그것은 file_operations구조체를 지시하는 포인터를 포함하고 있다. 새 파일을 등록할 때마다, /proc에서 그것에 접근하기 위해 어느 inode_operations 구조체를 사용할 것인지 결정한다. 우리가 사용할 module_input(), module_output()함수를 지시하는 포인터를 포함한 file_operation 구조체를 지시하는 포인터를 포함한 inode_operations 구조체, 이것이 우리가 사용하는 메커니즘이다.

읽기와 쓰기를 위한 표준 롤 셋이 커널에서는 반대로 지정돼있다는 것을 명심하자. 읽기 함수는 출력을 위해, 반대로 쓰기함수는 입력을 위해 사용 된다. 일기와 쓰기는 사용자의 관점에서 본 것이기 때문이다. --- 만일 프로세스가 커널에서 무언가 읽는다면 커널은 그것을 출력해 주어야 한다. 그리고 프로세스가 커널에 무언가를 쓴다면 커널은 그것을 입력으로 받아 들여야 한다.

흥미 있는 또 다른 것은 module_permissions() 함수다. 프로세스가 /proc 파일에 무언가를 하려고 할 때마다, 이 함수는 호출 된다. 그리고 이 함수는 이 접근을 허용할 것인가 말 것인가를 결정하게 된다. 당장은 이것이 현재 사용자의 uid와 행위(operation) 자체에만 근거 하지만, (그리고 이것은 현재 실행되는 프로세스의 정보를 담고 있는 구조체의 포인터에서 찾아 질 수 있는 것들) 이것은 프로세스가 무엇을 하는 것인가, 작업 시각, 마지막으로 무엇을 입력 받았는가 등, 우라기 원하는 어떤 것에 근거할 수도 있다.

인텔 아키텍쳐에서(물론 다른 프로세서 하에서는 달라질 수도 있지만) put_user() 매크로와 get_user()매크로를 사용하는 이유는 리눅스의 메모리가 세그먼트 이기 때문이다. 포인터 자체는 유니크한 메모리 위치를 지시할 수 없고, 메모리 세그먼트 위치만 지시할 수 있다. 또한 어느 메모리 세그먼트를 사용할 수 있는지 알 필요가 있다. 커널을 위한 메모리 하나의 세그먼트가 있고, 각 프로세스들마다 하나의 세그먼트가 존재한다.

프로세스 자신의 메모리 세그먼트에만 접근이 가능하다. 그래서 일반적인 프로그램이 프로세스로서 실행될 때 세그먼트에 관해 신경 쓰지 않아도 된다. 커널 모듈을 작성할 때, 일반적으로 시스템에 의해 자동으로 다뤄지는 커널 메모리 세그먼트에 접근하기를 원한다. 그러나 메머리 버퍼의 내용이 현재 실행 중인 프로세스와 커널 사이에서 전달 되야 할 때, 커널 함수는 프로세스 세그먼트에 있는 메모리 포인터를 받게 된다. put_user() 매크로와 get_user() 매크로가 그 메모리에 접근 가능케 해준다.

Example 6-1. procfs.c

디바이스 파일은 물리적 장치를 나타내는 것으로 간주된다. 대부분의 물리적 장치들은 입출력을 위해 사용된다. 그래서 커널 안에서 디바이스 드라이버가 프로세스로부터 디바이스로 보낼 아웃풋을 얻기 위해 특별한 메커니즘이 필요하다. 파일에 쓰기를 하는 것처럼, 아웃풋을 쓰기 위해 디바이스 파일을 오픈 하는 것으로 된다. 다음의 예에서 이것은 device_write()함수에 의해 구현된다.

이것으로 항상 충분한 것은 아니다. 모뎀에 연결된 시리얼 포트가 있다고 상상해보자. (내장 모뎀이라 해도 CPU의 관점에서 모뎀에 시리얼 포트가 연결된 것으로 구현된다. 너무 지나치게 깊이 상상하지 말자). 해야 할 것은 디바이스 파일을 이용해 모뎀에 무언가(모뎀 명령어 혹은 전화선을 통해 나가는 데이터)를 기록하는 것이고, 모뎀으로부터 무언가(명령에 대한 응답, 혹은 전화선을 통한 데이터)를 읽어 오는 것이다. 예를 들어 어떤 속도록 데이터를 보낼 것인가? 와 같은 질문은 여전히 남는다.

유닉스에서 Input Output Control 의 준 말인ioctl()이라는 특수한 함수를 호출하는 것이 답이 된다. 모든 디바이스드라이버는 자신만의 ioctl 명령을 갖을 수 있고, 그리고 그것은 읽기를 위한 ioctl 커맨드(프로세스로부터 커널로 정보를 보내는 )이거나 쓰기를 위한 ioctl 커맨드(프로세스로 정보를 돌리는), 혹은 둘 모두, 혹은 둘 모드 아니다. ioctl함수는 다음과 같은 세 개의 인자를 가진다. 해당되는 디바이스 파일의 디스크립터, ioctl번호, 롱형으로 어떤 타입으로던지 케스팅후 사용할 수 있는 인자2

ioctl의 번호는 장치 주번호, ioctl의 타입(읽기/쓰기), 커맨드, 인자의 타입으로 만들어 진다. 이 ioctl 번호는 헤더파일에 있는 _IO, _IOR, _IOW or _IOWR(이들은 보통 타입에 따라 달리 쓰임) 와 같은 매크로에 의해 보통 만들어진다. 헤더 파일은 ioctl을 사용하는 프로그램(적당한 ioctl명령을 만들기 위해 )이나, 커널 모듈(만들어 진 ioctl명령을 이해하기 위해) 모두에 포함되야 한다. 다음의 예에서, chardev.h가 헤더 파일이고 그것을 사용하는 프로그램은 ioctl.c이다.

만일 당신의 커널 모듈에서 ioctl을 사용하기 원한다면, ioctl 명령을 할당하는 것이 가장 좋다. 그래서 우연히 다른 사람의 ioctl 커맨드를 받게 되거나, 다른 사람이 당신의 ioctl커맨드를 받아도 그것이 잘못됐다는 것을 알게 된다. 좀더 많은 정보를 위해서 커널소스의 Documentation/ioctl-number.txt파일을 참고하길 바란다.

Example 7-1. chardev.c

Example 7-2. chardev.h

Example 7-3. ioctl.c