diff options
Diffstat (limited to 'Documentation/kbuild/modules.txt')
-rw-r--r-- | Documentation/kbuild/modules.txt | 387 |
1 files changed, 189 insertions, 198 deletions
diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index 0767cf69c69e..799b6835993f 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt | |||
@@ -1,215 +1,185 @@ | |||
1 | Building External Modules | ||
1 | 2 | ||
2 | In this document you will find information about: | 3 | This document describes how-to build an out-of-tree kernel module. |
3 | - how to build external modules | ||
4 | - how to make your module use the kbuild infrastructure | ||
5 | - how kbuild will install a kernel | ||
6 | - how to install modules in a non-standard location | ||
7 | 4 | ||
8 | === Table of Contents | 5 | === Table of Contents |
9 | 6 | ||
10 | === 1 Introduction | 7 | === 1 Introduction |
11 | === 2 How to build external modules | 8 | === 2 How-to Build External Modules |
12 | --- 2.1 Building external modules | 9 | --- 2.1 Command Syntax |
13 | --- 2.2 Available targets | 10 | --- 2.2 Options |
14 | --- 2.3 Available options | 11 | --- 2.3 Targets |
15 | --- 2.4 Preparing the kernel tree for module build | 12 | --- 2.4 Building Separate Files |
16 | --- 2.5 Building separate files for a module | 13 | === 3. Creating a Kbuild File for an External Module |
17 | === 3. Example commands | 14 | --- 3.1 Shared Makefile |
18 | === 4. Creating a kbuild file for an external module | 15 | --- 3.2 Separate Kbuild file and Makefile |
19 | === 5. Include files | 16 | --- 3.3 Binary Blobs |
20 | --- 5.1 How to include files from the kernel include dir | 17 | --- 3.4 Building Multiple Modules |
21 | --- 5.2 External modules using an include/ dir | 18 | === 4. Include files |
22 | --- 5.3 External modules using several directories | 19 | --- 4.1 How to include files from the kernel include dir |
23 | === 6. Module installation | 20 | --- 4.2 External modules using an include/ dir |
24 | --- 6.1 INSTALL_MOD_PATH | 21 | --- 4.3 External modules using several directories |
25 | --- 6.2 INSTALL_MOD_DIR | 22 | === 5. Module installation |
26 | === 7. Module versioning & Module.symvers | 23 | --- 5.1 INSTALL_MOD_PATH |
27 | --- 7.1 Symbols from the kernel (vmlinux + modules) | 24 | --- 5.2 INSTALL_MOD_DIR |
28 | --- 7.2 Symbols and external modules | 25 | === 6. Module versioning & Module.symvers |
29 | --- 7.3 Symbols from another external module | 26 | --- 6.1 Symbols from the kernel (vmlinux + modules) |
30 | === 8. Tips & Tricks | 27 | --- 6.2 Symbols and external modules |
31 | --- 8.1 Testing for CONFIG_FOO_BAR | 28 | --- 6.3 Symbols from another external module |
29 | === 7. Tips & Tricks | ||
30 | --- 7.1 Testing for CONFIG_FOO_BAR | ||
32 | 31 | ||
33 | 32 | ||
34 | 33 | ||
35 | === 1. Introduction | 34 | === 1. Introduction |
36 | 35 | ||
37 | kbuild includes functionality for building modules both | 36 | "kbuild" is the build system used by the Linux kernel. Modules must use |
38 | within the kernel source tree and outside the kernel source tree. | 37 | kbuild to stay compatible with changes in the build infrastructure and |
39 | The latter is usually referred to as external or "out-of-tree" | 38 | to pick up the right flags to "gcc." Functionality for building modules |
40 | modules and is used both during development and for modules that | 39 | both in-tree and out-of-tree is provided. The method for building |
41 | are not planned to be included in the kernel tree. | 40 | either is similar, and all modules are initially developed and built |
41 | out-of-tree. | ||
42 | 42 | ||
43 | What is covered within this file is mainly information to authors | 43 | Covered in this document is information aimed at developers interested |
44 | of modules. The author of an external module should supply | 44 | in building out-of-tree (or "external") modules. The author of an |
45 | a makefile that hides most of the complexity, so one only has to type | 45 | external module should supply a makefile that hides most of the |
46 | 'make' to build the module. A complete example will be presented in | 46 | complexity, so one only has to type "make" to build the module. This is |
47 | chapter 4, "Creating a kbuild file for an external module". | 47 | easily accomplished, and a complete example will be presented in |
48 | section 3. | ||
48 | 49 | ||
49 | 50 | ||
50 | === 2. How to build external modules | 51 | === 2. How-to Build External Modules |
51 | 52 | ||
52 | kbuild offers functionality to build external modules, with the | 53 | To build external modules, you must have a pre-built kernel available |
53 | prerequisite that there is a pre-built kernel available with full source. | 54 | that contains the configuration and header files used in the build. |
54 | A subset of the targets available when building the kernel is available | 55 | Also, the kernel must have been built with modules enabled. If you are |
55 | when building an external module. | 56 | using a distribution kernel, there will be a package for the kernel you |
57 | are running provided by your distribution. | ||
56 | 58 | ||
57 | --- 2.1 Building external modules | 59 | An alternative is to use the "make" target "modules_prepare." This will |
60 | make sure the kernel contains the information required. The target | ||
61 | exists solely as a simple way to prepare a kernel source tree for | ||
62 | building external modules. | ||
58 | 63 | ||
59 | Use the following command to build an external module: | 64 | NOTE: "modules_prepare" will not build Module.symvers even if |
65 | CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be | ||
66 | executed to make module versioning work. | ||
60 | 67 | ||
61 | make -C <path-to-kernel> M=`pwd` | 68 | --- 2.1 Command Syntax |
62 | 69 | ||
63 | For the running kernel use: | 70 | The command to build an external module is: |
64 | 71 | ||
65 | make -C /lib/modules/`uname -r`/build M=`pwd` | 72 | make -C <path_to_kernel_src> M=$PWD |
66 | 73 | ||
67 | For the above command to succeed, the kernel must have been | 74 | The kbuild system knows that an external module is being built |
68 | built with modules enabled. | 75 | due to the "M=<dir>" option given in the command. |
69 | 76 | ||
70 | To install the modules that were just built: | 77 | To build against the running kernel use: |
71 | 78 | ||
72 | make -C <path-to-kernel> M=`pwd` modules_install | 79 | make -C /lib/modules/`uname -r`/build M=$PWD |
73 | 80 | ||
74 | More complex examples will be shown later, the above should | 81 | Then to install the module(s) just built, add the target |
75 | be enough to get you started. | 82 | "modules_install" to the command: |
76 | 83 | ||
77 | --- 2.2 Available targets | 84 | make -C /lib/modules/`uname -r`/build M=$PWD modules_install |
78 | 85 | ||
79 | $KDIR refers to the path to the kernel source top-level directory | 86 | --- 2.2 Options |
80 | 87 | ||
81 | make -C $KDIR M=`pwd` | 88 | ($KDIR refers to the path of the kernel source directory.) |
82 | Will build the module(s) located in current directory. | ||
83 | All output files will be located in the same directory | ||
84 | as the module source. | ||
85 | No attempts are made to update the kernel source, and it is | ||
86 | a precondition that a successful make has been executed | ||
87 | for the kernel. | ||
88 | 89 | ||
89 | make -C $KDIR M=`pwd` modules | 90 | make -C $KDIR M=$PWD |
90 | The modules target is implied when no target is given. | ||
91 | Same functionality as if no target was specified. | ||
92 | See description above. | ||
93 | 91 | ||
94 | make -C $KDIR M=`pwd` modules_install | 92 | -C $KDIR |
95 | Install the external module(s). | 93 | The directory where the kernel source is located. |
96 | Installation default is in /lib/modules/<kernel-version>/extra, | 94 | "make" will actually change to the specified directory |
97 | but may be prefixed with INSTALL_MOD_PATH - see separate | 95 | when executing and will change back when finished. |
98 | chapter. | ||
99 | 96 | ||
100 | make -C $KDIR M=`pwd` clean | 97 | M=$PWD |
101 | Remove all generated files for the module - the kernel | 98 | Informs kbuild that an external module is being built. |
102 | source directory is not modified. | 99 | The value given to "M" is the absolute path of the |
100 | directory where the external module (kbuild file) is | ||
101 | located. | ||
103 | 102 | ||
104 | make -C $KDIR M=`pwd` help | 103 | --- 2.3 Targets |
105 | help will list the available target when building external | ||
106 | modules. | ||
107 | 104 | ||
108 | --- 2.3 Available options: | 105 | When building an external module, only a subset of the "make" |
106 | targets are available. | ||
109 | 107 | ||
110 | $KDIR refers to the path to the kernel source top-level directory | 108 | make -C $KDIR M=$PWD [target] |
111 | 109 | ||
112 | make -C $KDIR | 110 | The default will build the module(s) located in the current |
113 | Used to specify where to find the kernel source. | 111 | directory, so a target does not need to be specified. All |
114 | '$KDIR' represent the directory where the kernel source is. | 112 | output files will also be generated in this directory. No |
115 | Make will actually change directory to the specified directory | 113 | attempts are made to update the kernel source, and it is a |
116 | when executed but change back when finished. | 114 | precondition that a successful "make" has been executed for the |
115 | kernel. | ||
117 | 116 | ||
118 | make -C $KDIR M=`pwd` | 117 | modules |
119 | M= is used to tell kbuild that an external module is | 118 | The default target for external modules. It has the |
120 | being built. | 119 | same functionality as if no target was specified. See |
121 | The option given to M= is the directory where the external | 120 | description above. |
122 | module (kbuild file) is located. | ||
123 | When an external module is being built only a subset of the | ||
124 | usual targets are available. | ||
125 | 121 | ||
126 | make -C $KDIR SUBDIRS=`pwd` | 122 | modules_install |
127 | Same as M=. The SUBDIRS= syntax is kept for backwards | 123 | Install the external module(s). The default location is |
128 | compatibility. | 124 | /lib/modules/<kernel_release>/extra, but a prefix may |
125 | be added with INSTALL_MOD_PATH (discussed in section 5). | ||
129 | 126 | ||
130 | --- 2.4 Preparing the kernel tree for module build | 127 | clean |
128 | Remove all generated files in the module directory only. | ||
131 | 129 | ||
132 | To make sure the kernel contains the information required to | 130 | help |
133 | build external modules the target 'modules_prepare' must be used. | 131 | List the available targets for external modules. |
134 | 'modules_prepare' exists solely as a simple way to prepare | ||
135 | a kernel source tree for building external modules. | ||
136 | Note: modules_prepare will not build Module.symvers even if | ||
137 | CONFIG_MODVERSIONS is set. Therefore a full kernel build | ||
138 | needs to be executed to make module versioning work. | ||
139 | 132 | ||
140 | --- 2.5 Building separate files for a module | 133 | --- 2.4 Building Separate Files |
141 | It is possible to build single files which are part of a module. | ||
142 | This works equally well for the kernel, a module and even for | ||
143 | external modules. | ||
144 | Examples (module foo.ko, consist of bar.o, baz.o): | ||
145 | make -C $KDIR M=`pwd` bar.lst | ||
146 | make -C $KDIR M=`pwd` bar.o | ||
147 | make -C $KDIR M=`pwd` foo.ko | ||
148 | make -C $KDIR M=`pwd` / | ||
149 | |||
150 | |||
151 | === 3. Example commands | ||
152 | |||
153 | This example shows the actual commands to be executed when building | ||
154 | an external module for the currently running kernel. | ||
155 | In the example below, the distribution is supposed to use the | ||
156 | facility to locate output files for a kernel compile in a different | ||
157 | directory than the kernel source - but the examples will also work | ||
158 | when the source and the output files are mixed in the same directory. | ||
159 | |||
160 | # Kernel source | ||
161 | /lib/modules/<kernel-version>/source -> /usr/src/linux-<version> | ||
162 | 134 | ||
163 | # Output from kernel compile | 135 | It is possible to build single files that are part of a module. |
164 | /lib/modules/<kernel-version>/build -> /usr/src/linux-<version>-up | 136 | This works equally well for the kernel, a module, and even for |
165 | 137 | external modules. | |
166 | Change to the directory where the kbuild file is located and execute | ||
167 | the following commands to build the module: | ||
168 | 138 | ||
169 | cd /home/user/src/module | 139 | Example (The module foo.ko, consist of bar.o and baz.o): |
170 | make -C /usr/src/`uname -r`/source \ | 140 | make -C $KDIR M=$PWD bar.lst |
171 | O=/lib/modules/`uname-r`/build \ | 141 | make -C $KDIR M=$PWD baz.o |
172 | M=`pwd` | 142 | make -C $KDIR M=$PWD foo.ko |
143 | make -C $KDIR M=$PWD / | ||
173 | 144 | ||
174 | Then, to install the module use the following command: | ||
175 | 145 | ||
176 | make -C /usr/src/`uname -r`/source \ | 146 | === 3. Creating a Kbuild File for an External Module |
177 | O=/lib/modules/`uname-r`/build \ | ||
178 | M=`pwd` \ | ||
179 | modules_install | ||
180 | 147 | ||
181 | If you look closely you will see that this is the same command as | 148 | In the last section we saw the command to build a module for the |
182 | listed before - with the directories spelled out. | 149 | running kernel. The module is not actually built, however, because a |
150 | build file is required. Contained in this file will be the name of | ||
151 | the module(s) being built, along with the list of requisite source | ||
152 | files. The file may be as simple as a single line: | ||
183 | 153 | ||
184 | The above are rather long commands, and the following chapter | 154 | obj-m := <module_name>.o |
185 | lists a few tricks to make it all easier. | ||
186 | 155 | ||
156 | The kbuild system will build <module_name>.o from <module_name>.c, | ||
157 | and, after linking, will result in the kernel module <module_name>.ko. | ||
158 | The above line can be put in either a "Kbuild" file or a "Makefile." | ||
159 | When the module is built from multiple sources, an additional line is | ||
160 | needed listing the files: | ||
187 | 161 | ||
188 | === 4. Creating a kbuild file for an external module | 162 | <module_name>-y := <src1>.o <src2>.o ... |
189 | 163 | ||
190 | kbuild is the build system for the kernel, and external modules | 164 | NOTE: Further documentation describing the syntax used by kbuild is |
191 | must use kbuild to stay compatible with changes in the build system | 165 | located in Documentation/kbuild/makefiles.txt. |
192 | and to pick up the right flags to gcc etc. | ||
193 | 166 | ||
194 | The kbuild file used as input shall follow the syntax described | 167 | The examples below demonstrate how-to create a build file for the |
195 | in Documentation/kbuild/makefiles.txt. This chapter will introduce a few | 168 | module 8123.ko, which is built from the following files: |
196 | more tricks to be used when dealing with external modules. | ||
197 | 169 | ||
198 | In the following a Makefile will be created for a module with the | ||
199 | following files: | ||
200 | 8123_if.c | 170 | 8123_if.c |
201 | 8123_if.h | 171 | 8123_if.h |
202 | 8123_pci.c | 172 | 8123_pci.c |
203 | 8123_bin.o_shipped <= Binary blob | 173 | 8123_bin.o_shipped <= Binary blob |
204 | 174 | ||
205 | --- 4.1 Shared Makefile for module and kernel | 175 | --- 3.1 Shared Makefile |
206 | 176 | ||
207 | An external module always includes a wrapper Makefile supporting | 177 | An external module always includes a wrapper makefile that |
208 | building the module using 'make' with no arguments. | 178 | supports building the module using "make" with no arguments. |
209 | The Makefile provided will most likely include additional | 179 | This target is not used by kbuild; it is only for convenience. |
210 | functionality such as test targets etc. and this part shall | 180 | Additional functionality, such as test targets, can be included |
211 | be filtered away from kbuild since it may impact kbuild if | 181 | but should be filtered out from kbuild due to possible name |
212 | name clashes occurs. | 182 | clashes. |
213 | 183 | ||
214 | Example 1: | 184 | Example 1: |
215 | --> filename: Makefile | 185 | --> filename: Makefile |
@@ -219,11 +189,11 @@ following files: | |||
219 | 8123-y := 8123_if.o 8123_pci.o 8123_bin.o | 189 | 8123-y := 8123_if.o 8123_pci.o 8123_bin.o |
220 | 190 | ||
221 | else | 191 | else |
222 | # Normal Makefile | 192 | # normal makefile |
193 | KDIR ?= /lib/modules/`uname -r`/build | ||
223 | 194 | ||
224 | KERNELDIR := /lib/modules/`uname -r`/build | 195 | default: |
225 | all:: | 196 | $(MAKE) -C $(KDIR) M=$$PWD |
226 | $(MAKE) -C $(KERNELDIR) M=`pwd` $@ | ||
227 | 197 | ||
228 | # Module specific targets | 198 | # Module specific targets |
229 | genbin: | 199 | genbin: |
@@ -231,15 +201,20 @@ following files: | |||
231 | 201 | ||
232 | endif | 202 | endif |
233 | 203 | ||
234 | In example 1, the check for KERNELRELEASE is used to separate | 204 | The check for KERNELRELEASE is used to separate the two parts |
235 | the two parts of the Makefile. kbuild will only see the two | 205 | of the makefile. In the example, kbuild will only see the two |
236 | assignments whereas make will see everything except the two | 206 | assignments, whereas "make" will see everything except these |
237 | kbuild assignments. | 207 | two assignments. This is due to two passes made on the file: |
208 | the first pass is by the "make" instance run on the | ||
209 | command line; the second pass is by the kbuild system, which is | ||
210 | initiated by the parameterized "make" in the default target. | ||
238 | 211 | ||
239 | In recent versions of the kernel, kbuild will look for a file named | 212 | --- 3.2 Separate Kbuild File and Makefile |
240 | Kbuild and as second option look for a file named Makefile. | 213 | |
241 | Utilising the Kbuild file makes us split up the Makefile in example 1 | 214 | In newer versions of the kernel, kbuild will first look for a |
242 | into two files as shown in example 2: | 215 | file named "Kbuild", and only if that is not found, will it |
216 | then look for a makefile. Utilizing a "Kbuild" file allows us | ||
217 | to split up the makefile from example 1 into two files: | ||
243 | 218 | ||
244 | Example 2: | 219 | Example 2: |
245 | --> filename: Kbuild | 220 | --> filename: Kbuild |
@@ -247,20 +222,21 @@ following files: | |||
247 | 8123-y := 8123_if.o 8123_pci.o 8123_bin.o | 222 | 8123-y := 8123_if.o 8123_pci.o 8123_bin.o |
248 | 223 | ||
249 | --> filename: Makefile | 224 | --> filename: Makefile |
250 | KERNELDIR := /lib/modules/`uname -r`/build | 225 | KDIR ?= /lib/modules/`uname -r`/build |
251 | all:: | 226 | |
252 | $(MAKE) -C $(KERNELDIR) M=`pwd` $@ | 227 | default: |
228 | $(MAKE) -C $(KDIR) M=$$PWD | ||
253 | 229 | ||
254 | # Module specific targets | 230 | # Module specific targets |
255 | genbin: | 231 | genbin: |
256 | echo "X" > 8123_bin.o_shipped | 232 | echo "X" > 8123_bin.o_shipped |
257 | 233 | ||
234 | The split in example 2 is questionable due to the simplicity of | ||
235 | each file; however, some external modules use makefiles | ||
236 | consisting of several hundred lines, and here it really pays | ||
237 | off to separate the kbuild part from the rest. | ||
258 | 238 | ||
259 | In example 2, we are down to two fairly simple files and for simple | 239 | The next example shows a backward compatible version. |
260 | files as used in this example the split is questionable. But some | ||
261 | external modules use Makefiles of several hundred lines and here it | ||
262 | really pays off to separate the kbuild part from the rest. | ||
263 | Example 3 shows a backward compatible version. | ||
264 | 240 | ||
265 | Example 3: | 241 | Example 3: |
266 | --> filename: Kbuild | 242 | --> filename: Kbuild |
@@ -269,13 +245,15 @@ following files: | |||
269 | 245 | ||
270 | --> filename: Makefile | 246 | --> filename: Makefile |
271 | ifneq ($(KERNELRELEASE),) | 247 | ifneq ($(KERNELRELEASE),) |
248 | # kbuild part of makefile | ||
272 | include Kbuild | 249 | include Kbuild |
250 | |||
273 | else | 251 | else |
274 | # Normal Makefile | 252 | # normal makefile |
253 | KDIR ?= /lib/modules/`uname -r`/build | ||
275 | 254 | ||
276 | KERNELDIR := /lib/modules/`uname -r`/build | 255 | default: |
277 | all:: | 256 | $(MAKE) -C $(KDIR) M=$$PWD |
278 | $(MAKE) -C $(KERNELDIR) M=`pwd` $@ | ||
279 | 257 | ||
280 | # Module specific targets | 258 | # Module specific targets |
281 | genbin: | 259 | genbin: |
@@ -283,28 +261,41 @@ following files: | |||
283 | 261 | ||
284 | endif | 262 | endif |
285 | 263 | ||
286 | The trick here is to include the Kbuild file from Makefile, so | 264 | Here the "Kbuild" file is included from the makefile. This |
287 | if an older version of kbuild picks up the Makefile, the Kbuild | 265 | allows an older version of kbuild, which only knows of |
288 | file will be included. | 266 | makefiles, to be used when the "make" and kbuild parts are |
267 | split into separate files. | ||
289 | 268 | ||
290 | --- 4.2 Binary blobs included in a module | 269 | --- 3.3 Binary Blobs |
291 | 270 | ||
292 | Some external modules needs to include a .o as a blob. kbuild | 271 | Some external modules need to include an object file as a blob. |
293 | has support for this, but requires the blob file to be named | 272 | kbuild has support for this, but requires the blob file to be |
294 | <filename>_shipped. In our example the blob is named | 273 | named <filename>_shipped. When the kbuild rules kick in, a copy |
295 | 8123_bin.o_shipped and when the kbuild rules kick in the file | 274 | of <filename>_shipped is created with _shipped stripped off, |
296 | 8123_bin.o is created as a simple copy off the 8213_bin.o_shipped file | 275 | giving us <filename>. This shortened filename can be used in |
297 | with the _shipped part stripped of the filename. | 276 | the assignment to the module. |
298 | This allows the 8123_bin.o filename to be used in the assignment to | 277 | |
299 | the module. | 278 | Throughout this section, 8123_bin.o_shipped has been used to |
279 | build the kernel module 8123.ko; it has been included as | ||
280 | 8123_bin.o. | ||
300 | 281 | ||
301 | Example 4: | ||
302 | obj-m := 8123.o | ||
303 | 8123-y := 8123_if.o 8123_pci.o 8123_bin.o | 282 | 8123-y := 8123_if.o 8123_pci.o 8123_bin.o |
304 | 283 | ||
305 | In example 4, there is no distinction between the ordinary .c/.h files | 284 | Although there is no distinction between the ordinary source |
306 | and the binary file. But kbuild will pick up different rules to create | 285 | files and the binary file, kbuild will pick up different rules |
307 | the .o file. | 286 | when creating the object file for the module. |
287 | |||
288 | --- 3.4 Building Multiple Modules | ||
289 | |||
290 | kbuild supports building multiple modules with a single build | ||
291 | file. For example, if you want to build two modules, foo and | ||
292 | bar, the kbuild lines would be: | ||
293 | |||
294 | obj-m := foo.o bar.o | ||
295 | foo-y := <foo_srcs> | ||
296 | bar-y := <bar_srcs> | ||
297 | |||
298 | It is that simple! | ||
308 | 299 | ||
309 | 300 | ||
310 | === 5. Include files | 301 | === 5. Include files |