모듈과 커널 버전
모듈은 커널 버전과 관련이 많습니다. 커널 버전에 맞춰서 모듈이 빌드되며, 커널의 버전과 모듈의 버전이 일치해야만 이용할 수 있습니다. 커널 소스에서 커널의 버전은 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커널)에서 확인 할 수 있습니다.
└ 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; }
모듈과 커널 심볼
모듈은 커널 영역에서 실행되기 때문에 표준 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
2.4 커널의 심볼
┌ 커널 내 심볼의 시작 주소
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 |
비자유 소프트웨어 |
'linux' 카테고리의 다른 글
새 프로세스 시작하기 (0) | 2010.08.15 |
---|---|
프로세스 일정 관리 (0) | 2010.08.14 |
프로세스와 신호 (0) | 2010.08.13 |
vim 설정 (0) | 2010.06.30 |
모듈의 상호참조 (0) | 2010.06.03 |
Hello 커널 모듈 작성 예제 (0) | 2010.06.02 |
모듈 개발. (0) | 2010.06.01 |
운영체제 커널 분류에대해... (0) | 2010.06.01 |
커널 소스 컴파일 (0) | 2010.06.01 |
/usr/lib/python2.4/site-packages/_sqlitecache.so: undefined symbol: g_assert_warning (0) | 2010.04.22 |