'Module'에 해당되는 글 2건

  1. 2015.03.13 [Linux] Module 관련
  2. 2015.03.09 [Makefile] Kbuild 와 Module Compile
2015.03.13 17:16



모듈과 커널 버전

모듈은 커널 버전과 관련이 많습니다. 커널 버전에 맞춰서 모듈이 빌드되며, 커널의 버전과 모듈의 버전이 일치해야만 이용할 수 있습니다. 커널 소스에서 커널의 버전은 include /linux/version.h에서 확인할 수 있습니다.

#define UTS_RELEASE "2.6.14.6"
#define LINUX_VERSION_CODE 132622
#define KERNEL_VERSION(a,b,c) (((a) << 16 ) + ((b) <<8)  +  (c))

따라서, 특정 버전 이상에서만 동작하는 모듈이라던가, 커널 버전에 따라 다르게 동작하는 모듈을 작성하고 싶다면 이를 활용해서 다음과 같은 코드를 작성할 수 있습니다.

#if LINUX_VERSION_CODE >= KERNEL_VERSION( 2, 6, 10)
MODULE_PARM( user_name, "charp");
#else
MODUILE_PARM( user_name, "s");
#elseif

MODULE_PARM()의 의미나 사용법은 나중에 설명을 한다. 여기서는 VERSION_CODE와 KERNEL_VERSION()사용한 방식만 이해하면 됩니다. KERNEL_VERSION()은 커널 버전 번호를 받아서 정수값으로 만들어 줍니다.  해당하는 커널 버전을 미리 정수 값으로 만들어둔 것이 LINUX_VERSION_CODE이고, 이것은 모든 커널에 선언되어 있습니다.

모듈과 static 선언

모듈 안에서만 사용되는 변수나 함수에는 static 키워드가 선언되어 있습니다. static은 메모리 내에 정적으로 위치하게 만드는 할을 하기 때문에 해당 소스 코드 내에서 전역으로 사용될 수 있습니다. 변수에 사용되면 전역변수가 되며, 함수에 사용되면 전역 함수가 되겟지요. 실제로 .c 코드 안에서 사용되는 모든 C 함수나 함수 바깥에 선언된 변수는 어디서나 상ㅇ할 수 있기 때문에 어떤 의미로는 항상 전역이라고 할 수 있습니다. 함수나 전역 변수에 사용된 static 의 다른 의미는 다른 .c소스 코드에서 접근할 수 없게하는 범위 지정자 입니다.

리눅스 커널은 커널 전체가 하나의 프로그램입니다. 그러니까 같은 이름을 가진 변수나 함수를 만들 수 없습니다. 누군가 A라는 모듈에서 hello()함수를 작성해서 커널 영역에 로드했다면, 또 다른 hello() 함수를 가진 모듈 B는 로드 할 수 없게 됩니다. 이 함수가 모듈 안에서만 사용되고, 다른 커널에서 참조할 필요가 전혀 없다면 이런 파일들은 커널 영역에서 보이지 않게 해야 합니다. 때문에 static을 사용합니다. init_module()과 cleanup_module()함수는 다소 예외적인 경우로는 이 함수는 static을 사용하지 않아도 커널 영역에 공개 되지 않습니다. 실제로, 이들 함수는 __init_module_inline()과 __exit_module() 함수는 다소 예외적인 경우로 이 함수는 static을 사용하지 않아도 커널 영역에 공개 되지 않습니다.  실제로 이들 함수는 __init_module_inline()과 __exit_module_inline() 같은 인라인 함수로 대체되어 실행되고, 이들 함수는 모두 static으로 선언되어 있기 때문에 커널 영역에서 공개되지 않습니다. 커널 영역에 공개된 함수는 /proc/ksyms(2.4커널) 이나 /proc/kallsysms(2.6커널)에서 확인 할 수 있습니다.

typedef int (*__init_module_fun_t)(void)
                            └ init_module()의 원형
typedef void (*__cleanup_module_func_t)(void);
#define module_init(x) \              └ cleanup_module()의 원형
   int init_module(void) __attribute__(alias(#3))); \
   static inline _init_module_func_t __init_module_inline(void) \
    └  커널 영역에 고액되지 않는 지역 함수로 선언됩니다.
   {  return x; }

#define module_exit (x) \
  void cleanup_module(void) __attribute__((alias(#x))); \

  static inline __cleanup_module_func_t__cleanup_module_inline(void) \
    └  커널 영역에 고액되지 않는 지역 함수로 선언됩니다.
  { return x; }
static으로 선언되어 있으면, 외부 C 소스 코드에서 extern 선언으로 참조할 수 없습ㄴ디ㅏ. 2.5 커널에서는 모듈 내에서 static 없이 선언된 함수는 커널 영역에 공개되었지만 2.6에서는 공개되지 않았습니다.

모듈과 커널 심볼

모듈은 커널 영역에서 실행되기 때문에 표준 C 함수들은 사용할 수 없습니다. 대신에, 커널 영역에서 사용할 수 있는 함수나 자료 구조의 목록을 커널에서 제공합니다. 이 목록은 2.4 커널에서는 /proc/ksyms, 2.6 커널에서는 /proc/kallsyms를 통해 제공합니다. printk()함수도 커널 심볼 파일에서 확인할 수 있습니다.

2.6 커널의 심볼

# grep printk /proc/kallsyms
.........     ┌ 심폴의 타입 정보
c011d6b0  T printk
c011d6b0  T vprintk
c011d6b0  T __printk_ratelimit
........                               ┌ 심폴의 타입 정보
c011d6b0  U printk        [vmhgfs]
c011d6b0  U printk        [vmxnet]
      |            └ 심볼 이름
                 └ 심볼 이름

심볼 타입

설명

A

절대 주소로 변경되지 않음

B

bss 영역의 심볼

C

공용 심볼로 초기화되지 않은 변수를 의미

D

data 영역의 심볼로 초기화된 변수를 의미

R

rdata 영역, 즉 읽기 전용변수를 의미

T

text 영역의 심볼로 함수를 의미

U

해당 모듈에서 정의하지 않은 (undefined) 심폴을 의미

I

다른 심볼에 대한 간접(Indirect) 참조를 의미하는 GNU 확장

N

디버깅 심볼

- 심볼의 타입 -

printk() 함수를 사용하는 모듈이 있으면 printk()함수를 이용하는 모듈 이름과 함께 printk()에 대한 심볼 타입이 "U"로 나타납니다. 직접 작성한 모듈에서 printk() 함수를 정의한 것이 아니기 떄문에 그렇습니다. 심볼 타입이 대문자로 사용되면 전역 심볼을 의미하고, 소문자로 되어 있으면 지역 심볼을 의미합니다.


심볼 : 2.4와 2.6의 차이

2.4 커널에서는 모듈 안에서 static으로 선언되지 않은 함수들이 모두 커널 심볼로 공개되어 있습니다. 2.6커널에서는 static으로 선언되지 않은 함수여도, 커널 심볼로 등록 하지 않으면 공개되지 않게 변경되었습니다.

커널 심볼로 공개시키는 방법은 EXPORT_SYMBL()이나 EXPORT_SYMBOL_GPL()과 같은 매크로를 사용해서 공개할 심볼을 지정하기만 하면 됩니다. printk() 함수의 경우 kernel/printk.c 에서 다음과 같은 부분을 확인할 수 있습니다.

kernel/printk.c

EXPORT_SYMBOL(printk);

이와 같이 정의되어 있기 때문에 외부 심볼로 공개되어 있으며, 커널이나 모듈 내에서 자유롭게 사용할 수 있습니다.

2.4 커널의 심볼
[/usr/src/linux-2.4.x.x #] grep printk /proc/ksyms

       ┌ 커널 내 심볼의 시작 주소
c0114aa0 printk_R1b7d4074
                       
└ 커널 버전과 심볼의 CRC 정보를 합한 값

2.6 커널의 /proc/kallsyms에서는 버전 정보를 제공하지 않습니다.
심볼과 관련된 매크로는 include/linux/module.h에 정의되어 있으며 알아야 될 것은 다음과 같습니다.

종류

설명

EXPORT_SYMBOL(var)

심볼을 공개합니다.

EXPORT_SYMBOL_NOVERS(var)

심볼을 버전정보 없이 공개합니다.

EXPORT_SYMBOL_GPL(var)

EXPORT_SYMBOL과 동일 하지만 GPL과 호환되는 라이선스로 등록한 모듈에서만 심볼을 볼 수 있습니다.

EXPORT_NO_SYMBOLS

모듈 내에서 어떤 심볼도 공개하지 않음을 정의합니다.

 - 심볼 매크로  -

EXPORT_NO_SYMBOLS는 모듀 내의 어디서나 한 줄만 넣어주면 되며, 해당 모듈에서 어떤 심볼도 공개하지 않음을 의미합니다. EXPORT_SYMBOL_GPL()은 MODULE_LICENSE()과 관련이 깊습니다.

모듈의 라이선스

리눅스 커널은 GPL라이선스를 따릅니다. 그리고 GPL 라이선스가 적용된 소스 코드를 수정한 경우 수정된 소스 코드를 공개해야 합니다. 일부 업체들은 오픈 소스를 이용해서 제품을 개발하지만 수정된 소스 코드를 공개해야 합니다. 일부 업체들은 오픈 소스를 이용해서 제품을 개발하지만 수정된 소스 코드를 공개하지 않아 물의를 사기도 했습니다. 매년 라이선스와 관련된 분쟁이 증가하고 있습니다. 때문에 모듈에서도 제작자가 원하는 라이선스를 지정하도록 했으면, 이 라이선스를 지정하지 않으면, 오픈소스인 커널에 상업적인 코드가 추가될 수 있고, 이는 커널의 오픈 소스를 위배할 수 있다는 경고를 보여줍니다.

module license 'unspecified' taints kernel.

현재 까지는 MODULE_LICENSE()를 통해 라이선스를 명시하지 않아도 문제는 없지만, 이런 라이선스 논쟁 이후 EXPORT_SYMBOL_GPL()이 추가 되었습니다. 이는, GPL과 호환되는 라이선스를 지정하지 않은 모듈에서는 커널의 기능을 사용할 수 없게 하는 정책을 추가하기 위한 것으로, 현재 이와 관련된 불이익은 없지만, 필요한 경우 GPL 호환 라이선스를 따르지 않는 상업적 코드들은 GPL코드를 이용할 수 없게 하기 위한 조치를 반영한것입니다.

MODULE_LICENSE()를 통해 지저앟ㄹ 수 있는 라이선스는 다음과 같다.

라이선스 종류

의미

GPL

GNU Public License v2 또는 이상

GPL v2

GNU Public License v2

GPL and additional rights

GNU Public License v2 right and more

Dual BSD/GPL

GNU Public License v2 또는 BSD 라이선스 선택

DUAL MPL/GPL

GPL v2 또는 모질라 라이선스 선택

Proprietary

비자유 소프트웨어



출처 : 리눅스 커널 프로그래밍  저 한동훈,원일용, 하홍준  / 한빛 미디어

신고

'Programming > Linux/Unix' 카테고리의 다른 글

디바이스 트리 작성법 (2편)  (1) 2015.03.24
디바이스 트리 작성법 (1편)  (0) 2015.03.24
[Linux] Module 관련  (0) 2015.03.13
[Makefile] Kbuild 와 Module Compile  (0) 2015.03.09
[Makefile] Device Driver  (0) 2015.03.09
Makefile 문법 및 관련 내용  (0) 2015.03.09


Posted by injunech
2015.03.09 17:38


Document/kbuild/makefile.txt 및 Document/kbuild/modules.txt 문서를 번역편집한 문서정리

출처좌표 : http://deepbluedawn.wordpress.com/2009/07/31/169/ 



이 문서는 리눅스 커널 2.6.x에 사용되는 kbuild System의 module build과정에 대해 설명하기 위한 문서입니다.Linux Kernel소스의 Documents/kbuild/makefiles.txt 및 Documents/kbuild/modules.txt문서를 번역및 편집한 것입니다. 따라서 상당부분이 난해하기도 하고 직역을 한 부분이 있으니 이해해 주셨으면 합니다. 번역이 매끄럽지 못한 부분은 반드시 원문을 읽어 영어 단어의 뜻을 파악하시기 바랍니다.

1.Kbuild system?

일반적인 리눅스 Application 개발자라 하더라도 커널 Makefile이 어떻게 동작하는지 아는 것이 좋은 경우가 많다. 단순히 새로운 커널을 컴파일해 설치해 사용하는 사용자가 아니고 시스템을 아우르는 어플리케이션 개발자라면 커널이 어떻게 만들어지는 알고 있는 것이 도움이 될 때가 많기 때문이다. 예를 들어 현재 설정에 의해 어떤 모듈이 어떤 파일로 이루어져 있는지 알수 있으면 그 파일들을 조사해 수정하거나 하는 일이 가능하다.

kbuild system은 리눅스 버젼 2.6.x대에 도입된 새로운 kernel build system이다.  kbuild는 kernel source tree 내부의 모듈들과 kernel source tree 외부의 모듈들에 대한 build를 지원한다.(후자의 경우 외부 혹은 “out-of-tree” 모듈이라고 불리우며 현재 개발 중이거나, 혹은 Kernel의 source tree에 포함되지  않는 module을 가리킬때 사용된다.)

외부 모듈 개발자들은 모든 복잡성을 숨길수 있는 간단한 하나의 makefile을 제공해야 하며, 이 makefile을 사용, 누구나  make 명령어를 통하여 module을 build할 수 있어야 한다.

1.1 Goal 정의

Goal 정의는 kbuild Makefile의 가장 중요한 부분이다. Goal은 Build과정을 통하여 최종적으로 만들어져할 것, 특별한 컴파일 옵션, 사용되야할 하위디렉토리를 정의한다. 가장 간단한 kbuild makefile은 다음과 같은 한 줄을 갖는다.

예:

obj-y += foo.o


이 예가 말하는 것은 이 디렉토리 내에 foo.o(foo.c나 foo.S로부터 만들어질)란 이름의 한개의 오브젝트가 있다는 것이다. 만약 foo.o가 모듈로 만들어진다면 obj-m이란 변수가 사용된다. 그래서 다음과 같은 예처럼 된다.

예:

obj-$(CONFIG_FOO) += foo.o


$(CONFIG_FOO)는 y(built-in을 의미)나 m(모듈을 의미)의 값을 갖는다. 만약 CONFIG_FOO가 y나 m의 값을 갖지 않는다면 이 파일은 컴파일되거나 링크되지 않는다.


1.2 Built-in 오브젝트 Goal (obj-y)

kbuild Makefile은 $(obj-y) 리스트 내에 vmlinux에 필요한 오브젝트 파일을 지정해 놓는다. kbuild는 모든 $(obj-y) 파일을 컴파일한다. 그리고 이런 모든 파일을 하나의 build-in.o로 만들기 위해 “$(LD) -r”을 부른다.

$(obj-y)에 기록된 파일의 순서는 매우 중요하다. 중복되서 나열되는 것도 허용되지만 첫번째로 나오는 것이 built-in.o에 링크되고 그 이후의 것은 무시된다. 어떤 기능 들은(예를 들어 module_init()나 __initcall) 부팅하는 동안 나타나는 순서대로 불려지기 때문에 링크 순서도 중요하다. 그래서 순서를 바꾸게되면 디스크 등의 드라이버가 사용되는 순서가 바뀌는 등의 일 때문에 디스크의 번호도 바뀔수 있다.

예:

#drivers/isdn/i4l/Makefile

# Makefile for the kernel ISDN subsystem and device drivers.

# Each configuration option enables a list of files.

obj-$(CONFIG_ISDN) += isdn.o

obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o


1.3. Loadable module goals(obj-m)

$(obj-m)은 적재 가능한 모듈을 만들 때 사용된다.

모듈은 하나의 소스 코드나 여러 개의 소스 코드에서 만들어질 수 있다. 하나의 소스 코드로 만들어지는 경우엔 그냥 $(obj-m)에 더하기만 하면 된다.

예:

#drivers/isdn/i4l/Makefile

obj-$(CONFIG_ISDN_PPP_BSDCOMP) += isdn_bsdcomp.o


Note: 이 예에서 $(CONFIG_ISDN_PPP_BSDCOMP)는 ‘m’을 나타낸다.


만약에 커널 모듈이 여러 개의 소스 파일로부터 만들어지면 위에 나온 것과 같은 방식으로 지정하면된다. kbuild는 만들고자하는 모듈이 어느 부분에서 오는지를 알면되고 $(<module_name>-objs)에 지정해 주면 된다.

예:

#drivers/isdn/i4l/Makefile

obj-$(CONFIG_ISDN) += isdn.o

isdn-objs := isdn_net_lib.o isdn_v110.o isdn_common.o


이 예에서 모듈 이름은 isdn.o이고 kbuild는 $(isdn-objs)안에 있는 오브젝트를 컴파일 한 후에 “$(LD) -r”을 실행해 isdn.o를 만들어낸다. kbuild는 오브젝트를 접미사 -objs와 -y에 의해 만들어지는 복합 오브젝트로 인식할 수 있다. 만약 오브젝트가 복합 오브젝트의 일부라면 Makefile이 CONFIG_ 값을 사용하도록 할 수 있다.

예:

#fs/ext2/Makefile

obj-$(CONFIG_EXT2_FS) += ext2.o

ext2-y := balloc.o bitmap.o

ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o

이 예에선 xattr.o는 $(CONFIG_EXT2_FS_XATTR)이 ‘y’인 경우에만 복합 오브젝트인 ext2.o의 일부 뿐이다. Note: 물론 커널 안에 모듈을 포함하는 경우에도 위와 같은 문법은 그대로 적용된다. 그래서 CONFIG_EXT2_FS=y인 경우 kbuild는 ext2.o 파일을 만들어 built-in.o에 링크하게된다.


2.외부 모듈을 build하는 방법


kbuild를 사용하여 외부 모듈을 build하기 위해서는 다음의 두 가지 사항이 구비 되어 있어야 한다.

Full source tree와 이를 사용하여 build된 kernel image가 있어야 한다.

Kernel을 build 할때 사용된 target들의 일부 부분이 module build를 위하여 사용 가능하여야 한다.


2.1 외부 modules을 build하는 방법

외부 module을 build하는 일반적인 3가지 방법에 대해서 알아보자.


일반적인 module build 방법

make -C <path-to-kernel> M=’pwd’

현재 동작중인 kernel을 참조하여 module을 build하는 경우.

make -C /lib/modules/’uname -r’/build M=’pwd’

Build된 kernel을 install하는 경우

make -C <path-to-kernel> M=’pwd’ modules_install

여기에서 간단히 짚고 넘어가야 할 부분은 세가지 정도이다. 먼저 make에서 -C option은 뒤의 parameter로 directory를 변경하라는 의미이고 uname -r 은 현재 운영중인 커널의 릴리즈 버젼 정보를 출력해 주는 명령어이다.

M과 modules_install등은 추후 설명할 build target 들이다.


2.2 외부 modules을 build하는 방법


make -C <path-to-kernel> M=’pwd’: pwd로 지정되어 있는 현재 directory의 모듈을 build하며, build과정에서 생성된 모든 출력 파일은 같은 directory에 저장된다. kernel source에 대한 갱신은 이루어지지 않으며, 반드시 적어도 한번은 kernel source가 성공적으로 build되어 있어야 한다.

make -C <path-to-kernel> M=’pwd’ module: 위의 방법에서 명시적으로 “module” 이라고 하는 target을 선언한 것이며 동작은 위의 서술과 동일하다.

make -C <path-to-kernel> M=’pwd’ modules_install: Build된 module을 설치한다. 설치되는 기본 directory는 /lib/modules/<kernel-version>/extra 이지만, prefix INSTALL_MOD_PATH를 통하여 설치되는 경로를 지정할 수 있다.

make -C <path-to-kernel> M=’pwd’ clean: 모듈 build과정에서 생성된 모든 file들을 삭제하며, kernel source directory는 변경되지 않는다.

make -C <path-to-kernel> M=’pwd’ help: 외부 모듈을 build하는데 필요한 build target들을 설명하는 명령이다.

2.3 사용가능한 option


make -C <path-to-kernel> M=’pwd’ M= 옵션은 kbuild에게 “외부 모듈”이 build되고 있다라는 사실을 알리는 옵션이며 SUBDIRS= 의 backward compatibility도 지원한다.


2.4 모듈 build를 위한 kernel tree 준비하기


외부 모듈을 build하기 위한 정보를 생성하기 위하여 kernel build target인 modules_prepare가 반드시 사용되어야 한다. (CONFIG_MODVERSIONS가 설정되어 있는 경우에도 modules_prepare target은 Module.symvers를 생성하지는 않는다. 조심할 것)


2.5 모듈의 파일 하나씩 build하기


kbuild는 하나의 모듈을 구성하는 각각의 파일들을 따로 build 할 수 있다.

(예)


make -C <path-to-kernel> M=’pwd’ bar.lst

make -C <path-to-kernel> M=’pwd’ bar.o

make -C <path-to-kernel> M=’pwd’ foo.ko

make -C <path-to-kernel> M=’pwd’ /


3. Kbuild/Makefile을 사용한 예제


kbuild system은 linux kernel을 효과적으로 build하기 위한 framework이다. Linux kernel과 밀접한 관련이 있는 kernel module은 다음과 같은 이유때문에 kbuild system을 사용하여야 한다.


전체 build system의 변경사항에 대하여 compatible하기 위하여

gcc등 compilation에 필요한 tool들과 해당 옵션들에 대하여 kernel build와 동일한 규칙을 적용하기 위하여

아래의 file들로 구성되어진 모듈을 compile하기 위하여 Makefile 하나를 생성해 보도록 하자.


8123_if.c

8123_if.h

8123_pci.c

8123_bin.o_shipped <- binary blob


3.1 모듈과 Kernel을 위한 공유 Makefile


외부 모듈은 항상 argument없이 단순한 ‘make’명령만으로 해당 module을 build할수 있는 wrapper Makefile을 포함하여야 한다.

Example 1:

–> filename: Makefile

ifneq ($(KERNELRELEASE),)

# kbuild part of makefile

obj-m  := 8123.o

8123-y := 8123_if.o 8123_pci.o 8123_bin.o

else

# Normal Makefile


KERNELDIR := /lib/modules/`uname -r`/build

all::

$(MAKE) -C $(KERNELDIR) M=`pwd` $@


# Module specific targets

genbin:

echo “X” > 8123_bin.o_shipped

endif


위의 예제에서 KERNELRELEASE 변수는 하나의 Makefile을 두 부분으로 나누는 역할을 수행한다. 위의 예제에서 make utility는 kbuild를 위한 두줄의 선언문만 인식을 못함에 비해 kbuild system은 두 라인의 선언문만 인식할 수 있다. 최근 version의 kernel에서 kbuild system은 먼저 Kbuild를 찾고 두번째 옵션으로 Makefile을 찾도록 되어 있다. Kbuild 파일을 사용하여 위의 예제에서 제공된 Makefile은 아래의 두가지 파일로 분리할 수 있다.


Example 2:

–> filename: Kbuild

obj-m  := 8123.o

8123-y := 8123_if.o 8123_pci.o 8123_bin.o

–> filename: Makefile

KERNELDIR := /lib/modules/`uname -r`/build

all::

$(MAKE) -C $(KERNELDIR) M=`pwd` $@

# Module specific targets

genbin:

echo “X” > 8123_bin.o_shipped


위의 예제에서는 상당히 작은 2개의 파일을 얻을 수 있었다. 그러나, 이렇게 작은 경우의 파일에 대해서 이러한 분리가 과현 실효성이 있는가에 대한 의문을 가질수 있으나, 매우 큰 Makefile의 경우, 이렇게 분리하는 것이 실효성을 가질수도 있다라는 점에 주목하자.

신고

'Programming > Linux/Unix' 카테고리의 다른 글

디바이스 트리 작성법 (2편)  (1) 2015.03.24
디바이스 트리 작성법 (1편)  (0) 2015.03.24
[Linux] Module 관련  (0) 2015.03.13
[Makefile] Kbuild 와 Module Compile  (0) 2015.03.09
[Makefile] Device Driver  (0) 2015.03.09
Makefile 문법 및 관련 내용  (0) 2015.03.09


Posted by injunech

티스토리 툴바