Linux Kernel 2.6.17
Documentation/Kbuild/modules.txt
refer from : http://www.gelato.unsw.edu.au/lxr/source/Documentation/kbuild/modules.txt
1
2 In this document you will find information about:
이 문서에서 다음의 정보를 얻을수 있습니다:
3 - how to build external modules
외부 모듈을 어떻게 빌드하는가.
4 - how to make your module use kbuild infrastructure
당신의 모듈을 kbuild 기반(infrastructure)으로 어떻게 빌드하는가.
5 - how kbuild will install a kernel
kbuild가 커널을 어떻게 인스톨하는가.
6 - how to install modules in a non-standard location
비-표준 장소(location)에 모듈을 인스톨하기 위해서 어떻게 해야 하는가.
7
8 === Table of Contents
9
10 === 1 Introduction
11 === 2 How to build external modules
12 --- 2.1 Building external modules
13 --- 2.2 Available targets
14 --- 2.3 Available options
15 --- 2.4 Preparing the kernel tree for module build
16 --- 2.5 Building separate files for a module
17 === 3. Example commands
18 === 4. Creating a kbuild file for an external module
19 === 5. Include files
20 --- 5.1 How to include files from the kernel include dir
21 --- 5.2 External modules using an include/ dir
22 --- 5.3 External modules using several directories
23 === 6. Module installation
24 --- 6.1 INSTALL_MOD_PATH
25 --- 6.2 INSTALL_MOD_DIR
26 === 7. Module versioning & Module.symvers
27 --- 7.1 Symbols fron the kernel (vmlinux + modules)
28 --- 7.2 Symbols and external modules
29 --- 7.3 Symbols from another external module
30 === 8. Tips & Tricks
31 --- 8.1 Testing for CONFIG_FOO_BAR
32
33
34
PS. 콩글리시가 어디 가겠음?
35 === 1. Introduction
36
37 kbuild includes functionality for building modules both
38 within the kernel source tree and outside the kernel source tree.
39 The latter is usually referred to as external modules and is used
40 both during development and for modules that are not planned to be
41 included in the kernel tree.
kbuild 는 커널 소스트리에 포함되거나 포함되지 않은 모듈(driver)들을 build하기위한 기능을 포함한다.
커널 소스트리에 포함되지 않은 모듈들은 외부 모듈로서 참조된다. 그리고 그것은 개발중이거나 커널 트리에 포함되지 않을 모듈들에서도 사용된다.
42
43 What is covered within this file is mainly information to authors
44 of modules. The author of an external modules should supply
45 a makefile that hides most of the complexity so one only has to type
46 'make' to build the module. A complete example will be present in
47 chapter 4, "Creating a kbuild file for an external module".
이 파일에는 모듈 제작자(author-저자-)에게 중요한 정보를 포함하고 있다.
외부 모듈들의 제작자는 복잡성을 숨긴 makefile을 제공해야 하며, 단순히 `make` 를 입력함으로서 모듈을 빌드할수 있도록 해야한다.
완벽한 예제는 4장(chapter) "외부모듈을 위한 kbuild 파일 만들기" 에서 볼수 있을것이다.
48
49
50 === 2. How to build external modules
외부 모듈을 빌드하는 방법.
51
52 kbuild offers functionality to build external modules, with the
53 prerequisite that there is a pre-built kernel available with full source.
54 A subset of the targets available when building the kernel is available
55 when building an external module.
kbuild는 pre-build된 커널및 전체 소스로 외부 모듈을 빌드하는 기능을 제공한다.
타겟의 부분집합(subset)은 커널을 빌드할때 이용할수 있고, 커널 빌드는 외부 모듈을 빌드할때 이용할 수 있다.
available : 이용할 수 있는, 소용이 되는, 쓸모 있는, 입수할 수 있는
prerequisite : 미리 필요한, 필수의, 전제가 되는
56
57 --- 2.1 Building external modules
외부 모듈 빌드.
58
59 Use the following command to build an external module:
외부 모듈을 빌드하기 위해서는 다음의 명령어를 써라.
60
61 make -C <path-to-kernel> M=`pwd`
62
63 For the running kernel use:
현재 실행중인 커널을 위해서는 다음의 명령어를 써라.
64 make -C /lib/modules/`uname -r`/build M=`pwd`
65
66 For the above command to succeed the kernel must have been built with
67 modules enabled.
앞서의 명령어가 성공하기 위해서는 커널모듈(커널의 모듈화 기능)이 활성화 된 상태로 빌드 되었어야 한다.
68
69 To install the modules that were just built:
방금 빌드한 모듈을 설치하기 위해서는 다음의 명령어를 써라.
70
71 make -C <path-to-kernel> M=`pwd` modules_install
72
73 More complex examples later, the above should get you going.
더 복잡한 예는 다음에, 위의 내용은 기본적으로 알아야할 내용임.
74
75 --- 2.2 Available targets
가능한 타겟들.
76
77 $KDIR refers to the path to the kernel source top-level directory
$KDIR 은 커널 소스의 최상위 경로를 참조(지정)한다.
78
79 make -C $KDIR M=`pwd`
80 Will build the module(s) located in current directory.
81 All output files will be located in the same directory
82 as the module source.
83 No attempts are made to update the kernel source, and it is
84 a precondition that a successful make has been executed
85 for the kernel.
위 명령어를 치면 현재 디렉토리에 모듈을 빌드할것이다. 모들 출력 파일들은 모듈 소스가 위치한 장소에 생성될것이다.
커널 소스를 업데이트 하려고 시도(attempt)하지 마라. 그리고 그것(커널 소스를 업데이트 하려는 시도를 하지 않는것)이 커널 모듈로서 잘 동작하기 위한 전제조건(precondition)이다.
86
87 make -C $KDIR M=`pwd` modules
88 The modules target is implied when no target is given.
89 Same functionality as if no target was specified.
90 See description above.
타겟을 주지 않는다면 모듈의 타겟은 암시적(implied)으로 설정된다. 타겟을 명시하지 않았을때와 동일한 동작을 한다. 앞서의 설명을 보라.
91
92 make -C $KDIR M=$PWD modules_install
93 Install the external module(s).
94 Installation default is in /lib/modules/<kernel-version>/extra,
95 but may be prefixed with INSTALL_MOD_PATH - see separate
96 chapter.
외부 모듈을 설치한다. 기본 경로는 /lib/modules/<kernel-version>/extra가 되며, INSTALL_MOD_PATH라는 접두사(prefix)를 붙일수 있다. - 분리된 챕터를 보라.
97
98 make -C $KDIR M=$PWD clean
99 Remove all generated files for the module - the kernel
100 source directory is not modified.
모든 생성된 파일들과 모듈을 제거한다. - 커널 소스 디렉토리는 영향을 받지 않는다.
101
102 make -C $KDIR M=`pwd` help
103 help will list the available target when building external
104 modules.
도움말은 외부 모듈을 빌드할때 가능한 타겟 리스트를 보여준다.
105
106 --- 2.3 Available options:
가능한 옵션들
107
108 $KDIR refers to the path to the kernel source top-level directory
$KDIR 은 커널 소스의 최상위 경로를 참조(지정)한다.
109
110 make -C $KDIR
111 Used to specify where to find the kernel source.
112 '$KDIR' represent the directory where the kernel source is.
113 Make will actually change directory to the specified directory
114 when executed but change back when finished.
전통적으로 커널의 소스를 찾을 경로를 명시한다.
`$KDIR`은 커널 소스가 존재하는 디렉토리를 나타낸다.
make 는 명시된 디렉토리로 변경했다가, 모든 실행을 완료하면, 다시 원래대로 복귀한다.
115
116 make -C $KDIR M=`pwd`
117 M= is used to tell kbuild that an external module is
118 being built.
119 The option given to M= is the directory where the external
120 module (kbuild file) is located.
121 When an external module is being built only a subset of the
122 usual targets are available.
M= 옵션은 kbuild에게 외부모듈이 빌드될거라는걸 알려준다.
M= 옵션은 외부모듈이 위치한 경로를 알려준다.
외부 모듈이 일반 타겟(usual target)의 서브셋일 경우에만 빌드된다. <-- 누가 설명좀..
123
124 make -C $KDIR SUBDIRS=`pwd`
125 Same as M=. The SUBDIRS= syntax is kept for backwards
126 compatibility.
M= 과 동일한 옵션임. SUBDIRS= 는 하위호환을 위한 문법이다.
127
128 --- 2.4 Preparing the kernel tree for module build
모듈 빌드를 위한 커널 트리 준비
129
130 To make sure the kernel contains the information required to
131 build external modules the target 'modules_prepare' must be used.
커널이 외부 모듈을 빌드하기 위한 정보를 포함하게 하게 위해서는 `modules_prepare`라는 타겟이 사용되어야만 한다.
132 'module_prepare' solely exists as a simple way to prepare
133 a kernel for building external modules.
`modules_prepare`는 외부 모듈을 빌드하기 위해 커널이 준비하기 위한 방법으로, 단독으로(solely) 존재한다.
134 Note: modules_prepare will not build Module.symvers even if
135 CONFIG_MODULEVERSIONING is set.
노트: modules_prepare 는 CONFIG_MODULEVERSION이 설정되어 있더라도 Module.symvers 파일을 작성하지 않는다.
136 Therefore a full kernel build needs to be executed to make
137 module versioning work.
따라서, 모듈 버전처리를 하기위해서는 전체 커널 빌드가 필요하다.
138
139 --- 2.5 Building separate files for a module
각각의 파일들을 빌드하기
140 It is possible to build single files which is part of a module.
모듈을 부분으로 나눠서 각각 빌드할 수 있다.
141 This works equal for the kernel, a module and even for external
142 modules.
커널이나, 모듈, 혹은 외부 모듈에도 모두 동일하게 동작한다.
143 Examples (module foo.ko, consist of bar.o, baz.o):
144 make -C $KDIR M=`pwd` bar.lst
145 make -C $KDIR M=`pwd` bar.o
146 make -C $KDIR M=`pwd` foo.ko
147 make -C $KDIR M=`pwd` /
148
149
150 === 3. Example commands
예제.
151
152 This example shows the actual commands to be executed when building
153 an external module for the currently running kernel.
현재 동작중인 커널용 외부 모듈을 작성하는 실제적인 예를 보여준다.
154 In the example below the distribution is supposed to use the
155 facility to locate output files for a kernel compile in a different
156 directory than the kernel source - but the examples will also work
157 when the source and the output files are mixed in the same directory.
다음의 예제에서는 소스파일과 실제 출력파일(바이너리모듈)이 별개의 디렉토리에 위치하게 된다. 하지만, 동일 디렉토리에 소스파일과 실제 출력파일이 혼재되어 있어도 문제는 없다.
158
159 # Kernel source (링크관계)
160 /lib/modules/<kernel-version>/source -> /usr/src/linux-<version>
161
162 # Output from kernel compile (링크관계)
163 /lib/modules/<kernel-version>/build -> /usr/src/linux-<version>-up
164
165 Change to the directory where the kbuild file is located and execute
166 the following commands to build the module:
kbuild 파일이 위치한 디렉토리로 이동해서, 모듈을 빌드하는 명령을 입력한다:
167
168 cd /home/user/src/module
169 make -C /usr/src/`uname -r`/source \
170 O=/lib/modules/`uname-r`/build \
171 M=`pwd`
172
173 Then to install the module use the following command:
다음의 명령을 통해 모듈을 설치한다:
174
175 make -C /usr/src/`uname -r`/source \
176 O=/lib/modules/`uname-r`/build \
177 M=`pwd` \
178 modules_install
179
180 If one looks closely you will see that this is the same commands as
181 listed before - with the directories spelled out.
만약 여기까지 주의깊게 본 사람이라면, 위의 명령어가 앞서 나왔던것과 동일하다는것을 알 수 있을것이다.
182
183 The above are rather long commands, and the following chapter
184 lists a few tricks to make it all easier.
위의 명령어들은 조금 길었다. 다음장에서는 몇가지 트릭을 사용하여, 좀더 간단히 만들어보자.
185
186
187 === 4. Creating a kbuild file for an external module
외부 모듈을위한 kbuild 파일 작성
188
189 kbuild is the build system for the kernel, and external modules
190 must use kbuild to stay compatible with changes in the build system
191 and to pick up the right flags to gcc etc.
kbuild 는 kernel용 빌드시스템이다. 그리고 외부 모듈은 올바른 gcc및 기타 툴들의 사용과 빌드 시스템의 변화에 호환되도록, 반드시 kbuild 를 사용해야 한다.
192
193 The kbuild file used as input shall follow the syntax described
194 in Documentation/kbuild/makefiles.txt. This chapter will introduce a few
195 more tricks to be used when dealing with external modules.
kbuild 파일은 Documentation/kbuild/makefiles.txt 문서에 따라 작성되어야 한다. 이 장에서는 외부 모듈을 다룰때 사용하는 몇가지 트릭을 소개하겠다.
96
197 In the following a Makefile will be created for a module with the
198 following files:
다음에 나오는 Makefile은 아래의 파일들을 위한 Makefile이다:
99 8123_if.c
200 8123_if.h
201 8123_pci.c
202 8123_bin.o_shipped <= Binary blob
203
204 --- 4.1 Shared Makefile for module and kernel
모듈과 커널을 위한 Shared Makefile.
205
206 An external module always includes a wrapper Makefile supporting
207 building the module using 'make' with no arguments.
208 The Makefile provided will most likely include additional
209 functionality such as test targets etc. and this part shall
210 be filtered away from kbuild since it may impact kbuild if
211 name clashes occurs.
외부 모듈은 make명령어게 별도의 인자를 주지않고 빌드하기위해서는 Makefile을 항상 포함해야한다. Makefile은 test target등 추가적인 기능들도 제공된다. 그리고 이 부분(추가적인 기능?)이 이름 문제로 인해 kbuild시스템에 문제를 일으킨다면 kbuild에서 필터링 될것이다.
212
213 Example 1:
214 --> filename: Makefile
215 ifneq ($(KERNELRELEASE),)
216 # kbuild part of makefile
217 obj-m := 8123.o
218 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
219
220 else
221 # Normal Makefile
222
223 KERNELDIR := /lib/modules/`uname -r`/build
224 all::
225 $(MAKE) -C $(KERNELDIR) M=`pwd` $@
226
227 # Module specific targets
228 genbin:
229 echo "X" > 8123_bin.o_shipped
230
231 endif
232
233 In example 1 the check for KERNELRELEASE is used to separate
234 the two parts of the Makefile. kbuild will only see the two
235 assignments whereas make will see everything except the two
236 kbuild assignments.
위의 example1에서 KERNELRELEASE가 Makefile을 두개의 부분으로 나누는데 사용되는것을 볼 수 있다. kbuild는 두개의 assignment(할당/임명)만을 인식하는데 반해, make는 kbuild가 인식하는 두개를 뺀 나머지를 모두 인식한다.
237
238 In recent versions of the kernel, kbuild will look for a file named
239 Kbuild and as second option look for a file named Makefile.
240 Utilising the Kbuild file makes us split up the Makefile in example 1
241 into two files as shown in example 2:
최신 버전의 커널에서는, kbuild는 Kbuild라는 파일을 먼저 살펴보고, 그 다음으로 Makefile을 확인한다. 아래에 보이는 example 2와 같이 example 1 에서의 내용을 Kbuild와 Makefile로 분리해서 작성할 수 있다.
242
243 Example 2:
244 --> filename: Kbuild
245 obj-m := 8123.o
246 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
247
248 --> filename: Makefile
249 KERNELDIR := /lib/modules/`uname -r`/build
250 all::
251 $(MAKE) -C $KERNELDIR M=`pwd` $@
252
253 # Module specific targets
254 genbin:
255 echo "X" > 8123_bin_shipped
256
257
258 In example 2 we are down to two fairly simple files and for simple
259 files as used in this example the split is questionable. But some
260 external modules use Makefiles of several hundred lines and here it
261 really pays off to separate the kbuild part from the rest.
262 Example 3 shows a backward compatible version.
아래 보이는 예제 3은 하위 호환이 되는 버전이다.
263
264 Example 3:
265 --> filename: Kbuild
266 obj-m := 8123.o
267 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
268
269 --> filename: Makefile
270 ifneq ($(KERNELRELEASE),)
271 include Kbuild
272 else
273 # Normal Makefile
274
275 KERNELDIR := /lib/modules/`uname -r`/build
276 all::
277 $(MAKE) -C $KERNELDIR M=`pwd` $@
278
279 # Module specific targets
280 genbin:
281 echo "X" > 8123_bin_shipped
282
283 endif
284
285 The trick here is to include the Kbuild file from Makefile so
286 if an older version of kbuild picks up the Makefile the Kbuild
287 file will be included.
여기서 쓰인 트릭은, Kbuild파일을 Makefile에서 include한 것이다. 따라서 만약 예전 버전의 kbuild시스템이 Makefile을 선택하더라도 Kbuild 파일이 Makefile에 포함될 것이다. (따라서, 하위 호환이 보장된다.)
288
289 --- 4.2 Binary blobs included in a module
모듈에 include된 바이너리 blobs(????)
290
291 Some external modules needs to include a .o as a blob. kbuild
292 has support for this, but requires the blob file to be named
293 <filename>_shipped. In our example the blob is named
294 8123_bin.o_shipped and when the kbuild rules kick in the file
295 8123_bin.o is created as a simple copy off the 8213_bin.o_shipped file
296 with the _shipped part stripped of the filename.
297 This allows the 8123_bin.o filename to be used in the assignment to
298 the module.
몇몇 외부 모듈은 .o를 blob로서 포함될 필요가 있다. kbuild는 이것(바이너리를 include하는것)을 지원한다. 하지만, blob파일은 <filename>_shipped 라는 이름이어야 한다. 아랴의 예제에서 blob는 8123_bin.o_shipped라는 이름이며, kbuild시스템이 8123_bin.o를 포함하는것은 8123_bin.o_shipped파일에서 _shipped부분을 제거해서 복사한 것이다. 이것은 8123_bin.o를 module을 생성하는데 사용되는것을 허용한다.
299
300 Example 4:
301 obj-m := 8123.o
302 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
303
304 In example 4 there is no distinction between the ordinary .c/.h files
305 and the binary file. But kbuild will pick up different rules to create
306 the .o file.
예제 4에서 평범한 .c/.h파일과 바이너리 파일을 사이의 distiction(???)은 없다. 하지만 kbuild는 .o를 생성하기 위해 다른 방법을 선택할 것이다.
307
308
309 === 5. Include files
파일을 include하기.
310
311 Include files are a necessity when a .c file uses something from another .c
312 files (not strictly in the sense of .c but if good programming practice is
313 used). Any module that consist of more than one .c file will have a .h file
314 for one of the .c files.
어떤 .c파일에서 다른 .c파일의 무언가를 사용하기 위해서는 파일을 include할 필요가 있다(꼭 .c일 필요는 없지만, 대부분 .c를 사용한다.). 하나 이상의 .c파일로 이루어진 모듈은 .c파일들을 위해서 .h 파일을 가질것이다.
315 - If the .h file only describes a module internal interface then the .h file
316 shall be placed in the same directory as the .c files.
- 만약 .h파일이 module internal interface를 나타낼 뿐이라면, .h파일은 .c파일들과 동일한 디렉토리에 위치해야 한다.
317 - If the .h files describe an interface used by other parts of the kernel
318 located in different directories, the .h files shall be located in
319 include/linux/ or other include/ directories as appropriate.
- 만약 .h 파일들이 다른 디렉토리의 커널파트에서 쓰이는 interface를 나타낸다면, .h파일은 include/linux나 include/ 디렉토리에 위치하는것이 알맞다.
320
321 One exception for this rule is larger subsystems that have their own directory
322 under include/ such as include/scsi. Another exception is arch-specific
323 .h files which are located under include/asm-$(ARCH)/*.
이 규칙의 하나의 예외는 include/scsi와 같이 include/디렉토리 아래에 거대한 서브시스템 디렉토리를 가지고 있는 경우이다. 또 하나의 예외는 arch-specific .h파일인데, 이는 include/asm-$(ARCH)/*에 위치해야 한다.
324
325 External modules have a tendency to locate include files in a separate include/
326 directory and therefore needs to deal with this in their kbuild file.
외부 모듈은 ??????????????????????????????????????????????????????????????????????????????
327
328 --- 5.1 How to include files from the kernel include dir
커널 include디렉토리에서 파일들 인클루드 하기
329
330 When a module needs to include a file from include/linux/ then one
331 just uses:
모듈이 include/linuc/에서 파일을 include하기 위해서는 다음과 같이 쓰면 된다.
332
333 #include <linux/modules.h>
334
335 kbuild will make sure to add options to gcc so the relevant
336 directories are searched.
337 Likewise for .h files placed in the same directory as the .c file.
kbuild는 gcc에 검색될 위치를 재 지정하는 옵션을 더한다. .c와 동일 디렉토리에 위치한 .h는 다음과 같은 형식으로 include할 수 있다.
338
339 #include "8123_if.h"
340
341 will do the job.
342
343 --- 5.2 External modules using an include/ dir
include/ 디렉토리를 사용하는 외부 모듈들.
344
345 External modules often locate their .h files in a separate include/
346 directory although this is not usual kernel style. When an external
347 module uses an include/ dir then kbuild needs to be told so.
348 The trick here is to use either EXTRA_CFLAGS (take effect for all .c
349 files) or CFLAGS_$F.o (take effect only for a single file).
외부 모듈들은 보통의 커널 스타일과는 달리 그들의 .h파일을 분리된 include/ 디렉토리에 위치시킨다.
만약 외부 모듈이 include/ 디렉토리를 사용한다면, kbuild는 그것을 알려주어야 한다. 여기에서 쓰이는 트릭은 EXTRA_CFLAGS(모든 .c파일에 영향을 미침)나 CFLAGS_$F.o (하나의 파일에 영향을 미침)이다.
350
351 In our example if we move 8123_if.h to a subdirectory named include/
352 the resulting Kbuild file would look like:
다음의 예는 우리가 8123_if.h 파일을 include/라는 서브 디렉토리에 위치시키고, Kbuild파일에 명시해 놓은 것이다.
353
354 --> filename: Kbuild
355 obj-m := 8123.o
356
357 EXTRA_CFLAGS := -Iinclude
358 8123-y := 8123_if.o 8123_pci.o 8123_bin.o
359
360 Note that in the assignment there is no space between -I and the path.
361 This is a kbuild limitation: there must be no space present.
노트 : -I와 경로 사이에 빈칸이 존재해서는 안됨. 이것은 kbuild의 제한 규정이다.
362
363 --- 5.3 External modules using several directories
몇개의 서브 디렉토리를 사용하는 외부 모듈들.
364
365 If an external module does not follow the usual kernel style but
366 decide to spread files over several directories then kbuild can
367 support this too.
만약 외부 모듈이 일반적인 커널 스타일을 따르지 않고, 몇개의 디렉토리에 파일들을 흩어놓았을 경우에도 kbuild는 이것을 지원할 수 있다.
368
369 Consider the following example:
370
371 |
372 +- src/complex_main.c
373 | +- hal/hardwareif.c
374 | +- hal/include/hardwareif.h
375 +- include/complex.h
376
377 To build a single module named complex.ko we then need the following
378 kbuild file:
complex.ko라는 모듈을 빌드하기 위해서는, 다음과 같은 kbuild파일이 필요하다.
379
380 Kbuild:
381 obj-m := complex.o
382 complex-y := src/complex_main.o
383 complex-y += src/hal/hardwareif.o
384
385 EXTRA_CFLAGS := -I$(src)/include
386 EXTRA_CFLAGS += -I$(src)src/hal/include
387
388
389 kbuild knows how to handle .o files located in another directory -
390 although this is NOT reccommended practice. The syntax is to specify
391 the directory relative to the directory where the Kbuild file is
392 located.
kbuild는 권장되는 방법이 아니지만, 다른 디렉토리에 위치한 .o파일을 어떻게 다루어야 할 지 알고있다. 문법은 kbuild파일이 위치한 경로를 기준으로 상대 경로를 사용한다.
393
394 To find the .h files we have to explicitly tell kbuild where to look
395 for the .h files. When kbuild executes current directory is always
396 the root of the kernel tree (argument to -C) and therefore we have to
397 tell kbuild how to find the .h files using absolute paths.
398 $(src) will specify the absolute path to the directory where the
399 Kbuild file are located when being build as an external module.
400 Therefore -I$(src)/ is used to point out the directory of the Kbuild
401 file and any additional path are just appended.
.h파일을 찾기위해서 우리는 명시적으로 .h를 찾기위해서 어디를 봐야하는지 알려줘야 한다. kbuild가 실행될때 현재 디렉토리는 항상 커널 트리(arguement to -C)의 루트이다. 따라서 우리는 kbuild가 .h파일을 어떻게 절대 경로를 사용하여 찾아야 하는지 알려주어야 한다. $(src)는 외부 모듈로 빌드될때 kbuild파일이 위치한 경로의 절대 경로를 명시한다.
402
403 === 6. Module installation
404
405 Modules which are included in the kernel are installed in the directory:
406
407 /lib/modules/$(KERNELRELEASE)/kernel
408
409 External modules are installed in the directory:
410
411 /lib/modules/$(KERNELRELEASE)/extra
412
413 --- 6.1 INSTALL_MOD_PATH
414
415 Above are the default directories, but as always some level of
416 customization is possible. One can prefix the path using the variable
417 INSTALL_MOD_PATH:
418
419 $ make INSTALL_MOD_PATH=/frodo modules_install
420 => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel
421
422 INSTALL_MOD_PATH may be set as an ordinary shell variable or as in the
423 example above be specified on the command line when calling make.
424 INSTALL_MOD_PATH has effect both when installing modules included in
425 the kernel as well as when installing external modules.
426
427 --- 6.2 INSTALL_MOD_DIR
428
429 When installing external modules they are default installed in a
430 directory under /lib/modules/$(KERNELRELEASE)/extra, but one may wish
431 to locate modules for a specific functionality in a separate
432 directory. For this purpose one can use INSTALL_MOD_DIR to specify an
433 alternative name than 'extra'.
434
435 $ make INSTALL_MOD_DIR=gandalf -C KERNELDIR \
436 M=`pwd` modules_install
437 => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf
438
439
440 === 7. Module versioning & Module.symvers
441
442 Module versioning is enabled by the CONFIG_MODVERSIONS tag.
443
444
덧글
JayJay 2008/10/10 16:45 # 답글
The latter는 outside the kernel source tree 이거요 ㅎㅎ저거 다 번역하는거에요@_@?
승네군 2008/10/10 16:49 # 답글
계획만이라도 거창해야..;;
도로시 2008/10/18 00:20 # 답글
댓글타고 놀러놨습니다. '-'티스토리는 개인 사정으로 살짝 닫아둔 거예요. 헤헤
온김에 링크 추가 하고 갈께요.
승네군 2008/10/19 03:06 # 삭제 답글
뭔가 민망한 블로그인데... 나중에 링크 추가한걸 민망해 하게 되실지도..;;;
써니 2008/11/09 11:54 # 답글
사진이 멋지다~ 그런데... 독수공방이라니... T.T
SeungRye 2008/11/10 21:17 # 삭제 답글
...T^T(I cant write hangul in linux...-.-;;;)
anyway, just T^T...