€•P      Œsphinx.addnodes”Œdocument”“”)”}”(Œ	rawsource”Œ ”Œchildren”]”(Œtranslations”ŒLanguagesNode”“”)”}”(hhh]”(h Œpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ
attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ	refdomain”Œstd”Œreftype”Œdoc”Œ	reftarget”Œ"/translations/zh_CN/kbuild/modules”Œmodname”NŒ	classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ"/translations/zh_TW/kbuild/modules”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ"/translations/it_IT/kbuild/modules”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ"/translations/ja_JP/kbuild/modules”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ"/translations/ko_KR/kbuild/modules”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒPortuguese (Brazilian)”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ"/translations/pt_BR/kbuild/modules”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh–sbah}”(h]”h ]”h"]”h$]”h&]”Œ	refdomain”h)Œreftype”h+Œ	reftarget”Œ"/translations/sp_SP/kbuild/modules”Œmodname”NŒ	classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h
hhŒ	_document”hŒsource”NŒline”NubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒBuilding External Modules”h]”hŒBuilding External Modules”…””}”(hh¼h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhh·h²hh³Œ</var/lib/git/docbuild/linux/Documentation/kbuild/modules.rst”h´KubhŒ	paragraph”“”)”}”(hŒBThis document describes how to build an out-of-tree kernel module.”h]”hŒBThis document describes how to build an out-of-tree kernel module.”…””}”(hhÍh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khh·h²hubh¶)”}”(hhh]”(h»)”}”(hŒIntroduction”h]”hŒIntroduction”…””}”(hhÞh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhhÛh²hh³hÊh´KubhÌ)”}”(hXq  "kbuild" is the build system used by the Linux kernel. Modules must use
kbuild to stay compatible with changes in the build infrastructure and
to pick up the right flags to the compiler. Functionality for building modules
both in-tree and out-of-tree is provided. The method for building
either is similar, and all modules are initially developed and built
out-of-tree.”h]”hXu  â€œkbuildâ€ is the build system used by the Linux kernel. Modules must use
kbuild to stay compatible with changes in the build infrastructure and
to pick up the right flags to the compiler. Functionality for building modules
both in-tree and out-of-tree is provided. The method for building
either is similar, and all modules are initially developed and built
out-of-tree.”…””}”(hhìh²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K
hhÛh²hubhÌ)”}”(hX‹  Covered in this document is information aimed at developers interested
in building out-of-tree (or "external") modules. The author of an
external module should supply a makefile that hides most of the
complexity, so one only has to type "make" to build the module. This is
easily accomplished, and a complete example will be presented in
section `Creating a Kbuild File for an External Module`_.”h]”(hXb  Covered in this document is information aimed at developers interested
in building out-of-tree (or â€œexternalâ€) modules. The author of an
external module should supply a makefile that hides most of the
complexity, so one only has to type â€œmakeâ€ to build the module. This is
easily accomplished, and a complete example will be presented in
section ”…””}”(hhúh²hh³Nh´NubhŒ	reference”“”)”}”(hŒ0`Creating a Kbuild File for an External Module`_”h]”hŒ-Creating a Kbuild File for an External Module”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œname”Œ-Creating a Kbuild File for an External Module”Œrefid”Œ-creating-a-kbuild-file-for-an-external-module”uh1j  hhúŒresolved”KubhŒ.”…””}”(hhúh²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KhhÛh²hubeh}”(h]”Œintroduction”ah ]”h"]”Œintroduction”ah$]”h&]”uh1hµhh·h²hh³hÊh´Kubh¶)”}”(hhh]”(h»)”}”(hŒHow to Build External Modules”h]”hŒHow to Build External Modules”…””}”(hj,  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj)  h²hh³hÊh´KubhÌ)”}”(hXB  To build external modules, you must have a prebuilt kernel available
that contains the configuration and header files used in the build.
Also, the kernel must have been built with modules enabled. If you are
using a distribution kernel, there will be a package for the kernel you
are running provided by your distribution.”h]”hXB  To build external modules, you must have a prebuilt kernel available
that contains the configuration and header files used in the build.
Also, the kernel must have been built with modules enabled. If you are
using a distribution kernel, there will be a package for the kernel you
are running provided by your distribution.”…””}”(hj:  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Khj)  h²hubhÌ)”}”(hŒçAn alternative is to use the "make" target "modules_prepare." This will
make sure the kernel contains the information required. The target
exists solely as a simple way to prepare a kernel source tree for
building external modules.”h]”hŒïAn alternative is to use the â€œmakeâ€ target â€œmodules_prepare.â€ This will
make sure the kernel contains the information required. The target
exists solely as a simple way to prepare a kernel source tree for
building external modules.”…””}”(hjH  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K"hj)  h²hubhÌ)”}”(hŒ¬NOTE: "modules_prepare" will not build Module.symvers even if
CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be
executed to make module versioning work.”h]”hŒ°NOTE: â€œmodules_prepareâ€ will not build Module.symvers even if
CONFIG_MODVERSIONS is set; therefore, a full kernel build needs to be
executed to make module versioning work.”…””}”(hjV  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K'hj)  h²hubh¶)”}”(hhh]”(h»)”}”(hŒCommand Syntax”h]”hŒCommand Syntax”…””}”(hjg  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjd  h²hh³hÊh´K,ubhŒblock_quote”“”)”}”(hXã  The command to build an external module is::

        $ make -C <path_to_kernel_dir> M=$PWD

The kbuild system knows that an external module is being built
due to the "M=<dir>" option given in the command.

To build against the running kernel use::

        $ make -C /lib/modules/`uname -r`/build M=$PWD

Then to install the module(s) just built, add the target
"modules_install" to the command::

        $ make -C /lib/modules/`uname -r`/build M=$PWD modules_install

Starting from Linux 6.13, you can use the -f option instead of -C. This
will avoid unnecessary change of the working directory. The external
module will be output to the directory where you invoke make.

        $ make -f /lib/modules/`uname -r`/build/Makefile M=$PWD
”h]”(hÌ)”}”(hŒ,The command to build an external module is::”h]”hŒ+The command to build an external module is:”…””}”(hj{  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K.hjw  ubhŒliteral_block”“”)”}”(hŒ%$ make -C <path_to_kernel_dir> M=$PWD”h]”hŒ%$ make -C <path_to_kernel_dir> M=$PWD”…””}”hj‹  sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1j‰  h³hÊh´K0hjw  ubhÌ)”}”(hŒpThe kbuild system knows that an external module is being built
due to the "M=<dir>" option given in the command.”h]”hŒtThe kbuild system knows that an external module is being built
due to the â€œM=<dir>â€ option given in the command.”…””}”(hj›  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K2hjw  ubhÌ)”}”(hŒ)To build against the running kernel use::”h]”hŒ(To build against the running kernel use:”…””}”(hj©  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K5hjw  ubjŠ  )”}”(hŒ.$ make -C /lib/modules/`uname -r`/build M=$PWD”h]”hŒ.$ make -C /lib/modules/`uname -r`/build M=$PWD”…””}”hj·  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´K7hjw  ubhÌ)”}”(hŒ[Then to install the module(s) just built, add the target
"modules_install" to the command::”h]”hŒ^Then to install the module(s) just built, add the target
â€œmodules_installâ€ to the command:”…””}”(hjÅ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K9hjw  ubjŠ  )”}”(hŒ>$ make -C /lib/modules/`uname -r`/build M=$PWD modules_install”h]”hŒ>$ make -C /lib/modules/`uname -r`/build M=$PWD modules_install”…””}”hjÓ  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´K<hjw  ubhÌ)”}”(hŒÊStarting from Linux 6.13, you can use the -f option instead of -C. This
will avoid unnecessary change of the working directory. The external
module will be output to the directory where you invoke make.”h]”hŒÊStarting from Linux 6.13, you can use the -f option instead of -C. This
will avoid unnecessary change of the working directory. The external
module will be output to the directory where you invoke make.”…””}”(hjá  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K>hjw  ubjv  )”}”(hŒ8$ make -f /lib/modules/`uname -r`/build/Makefile M=$PWD
”h]”hÌ)”}”(hŒ7$ make -f /lib/modules/`uname -r`/build/Makefile M=$PWD”h]”(hŒ$ make -f /lib/modules/”…””}”(hjó  h²hh³Nh´NubhŒtitle_reference”“”)”}”(hŒ
`uname -r`”h]”hŒuname -r”…””}”(hjý  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jû  hjó  ubhŒ/build/Makefile M=$PWD”…””}”(hjó  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KBhjï  ubah}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´KBhjw  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´K.hjd  h²hubeh}”(h]”Œcommand-syntax”ah ]”h"]”Œcommand syntax”ah$]”h&]”uh1hµhj)  h²hh³hÊh´K,ubh¶)”}”(hhh]”(h»)”}”(hŒOptions”h]”hŒOptions”…””}”(hj,  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj)  h²hh³hÊh´KEubjv  )”}”(hXE  ($KDIR refers to the path of the kernel source directory, or the path
of the kernel output directory if the kernel was built in a separate
build directory.)

You can optionally pass MO= option if you want to build the modules in
a separate directory.

make -C $KDIR M=$PWD [MO=$BUILD_DIR]

-C $KDIR
        The directory that contains the kernel and relevant build
        artifacts used for building an external module.
        "make" will actually change to the specified directory
        when executing and will change back when finished.

M=$PWD
        Informs kbuild that an external module is being built.
        The value given to "M" is the absolute path of the
        directory where the external module (kbuild file) is
        located.

MO=$BUILD_DIR
        Specifies a separate output directory for the external module.
”h]”(hÌ)”}”(hŒœ($KDIR refers to the path of the kernel source directory, or the path
of the kernel output directory if the kernel was built in a separate
build directory.)”h]”hŒœ($KDIR refers to the path of the kernel source directory, or the path
of the kernel output directory if the kernel was built in a separate
build directory.)”…””}”(hj>  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KGhj:  ubhÌ)”}”(hŒ\You can optionally pass MO= option if you want to build the modules in
a separate directory.”h]”hŒ\You can optionally pass MO= option if you want to build the modules in
a separate directory.”…””}”(hjL  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KKhj:  ubhÌ)”}”(hŒ$make -C $KDIR M=$PWD [MO=$BUILD_DIR]”h]”hŒ$make -C $KDIR M=$PWD [MO=$BUILD_DIR]”…””}”(hjZ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KNhj:  ubhŒdefinition_list”“”)”}”(hhh]”(hŒdefinition_list_item”“”)”}”(hŒÝ-C $KDIR
The directory that contains the kernel and relevant build
artifacts used for building an external module.
"make" will actually change to the specified directory
when executing and will change back when finished.
”h]”(hŒterm”“”)”}”(hŒ-C $KDIR”h]”hŒ-C $KDIR”…””}”(hju  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´KThjo  ubhŒ
definition”“”)”}”(hhh]”hÌ)”}”(hŒÓThe directory that contains the kernel and relevant build
artifacts used for building an external module.
"make" will actually change to the specified directory
when executing and will change back when finished.”h]”hŒ×The directory that contains the kernel and relevant build
artifacts used for building an external module.
â€œmakeâ€ will actually change to the specified directory
when executing and will change back when finished.”…””}”(hjˆ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KQhj…  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hjo  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´KThjj  ubjn  )”}”(hŒ¯M=$PWD
Informs kbuild that an external module is being built.
The value given to "M" is the absolute path of the
directory where the external module (kbuild file) is
located.
”h]”(jt  )”}”(hŒM=$PWD”h]”hŒM=$PWD”…””}”(hj¦  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´KZhj¢  ubj„  )”}”(hhh]”hÌ)”}”(hŒ§Informs kbuild that an external module is being built.
The value given to "M" is the absolute path of the
directory where the external module (kbuild file) is
located.”h]”hŒ«Informs kbuild that an external module is being built.
The value given to â€œMâ€ is the absolute path of the
directory where the external module (kbuild file) is
located.”…””}”(hj·  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KWhj´  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hj¢  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´KZhjj  ubjn  )”}”(hŒMMO=$BUILD_DIR
Specifies a separate output directory for the external module.
”h]”(jt  )”}”(hŒMO=$BUILD_DIR”h]”hŒMO=$BUILD_DIR”…””}”(hjÕ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´K]hjÑ  ubj„  )”}”(hhh]”hÌ)”}”(hŒ>Specifies a separate output directory for the external module.”h]”hŒ>Specifies a separate output directory for the external module.”…””}”(hjæ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K]hjã  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hjÑ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´K]hjj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jh  hj:  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´KGhj)  h²hubeh}”(h]”Œoptions”ah ]”h"]”Œoptions”ah$]”h&]”uh1hµhj)  h²hh³hÊh´KEubh¶)”}”(hhh]”(h»)”}”(hŒTargets”h]”hŒTargets”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj  h²hh³hÊh´K`ubjv  )”}”(hX½  When building an external module, only a subset of the "make"
targets are available.

make -C $KDIR M=$PWD [target]

The default will build the module(s) located in the current
directory, so a target does not need to be specified. All
output files will also be generated in this directory. No
attempts are made to update the kernel source, and it is a
precondition that a successful "make" has been executed for the
kernel.

modules
        The default target for external modules. It has the
        same functionality as if no target was specified. See
        description above.

modules_install
        Install the external module(s). The default location is
        /lib/modules/<kernel_release>/updates/, but a prefix may
        be added with INSTALL_MOD_PATH (discussed in section
        `Module Installation`_).

clean
        Remove all generated files in the module directory only.

help
        List the available targets for external modules.
”h]”(hÌ)”}”(hŒTWhen building an external module, only a subset of the "make"
targets are available.”h]”hŒXWhen building an external module, only a subset of the â€œmakeâ€
targets are available.”…””}”(hj)  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kbhj%  ubhÌ)”}”(hŒmake -C $KDIR M=$PWD [target]”h]”hŒmake -C $KDIR M=$PWD [target]”…””}”(hj7  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kehj%  ubhÌ)”}”(hX2  The default will build the module(s) located in the current
directory, so a target does not need to be specified. All
output files will also be generated in this directory. No
attempts are made to update the kernel source, and it is a
precondition that a successful "make" has been executed for the
kernel.”h]”hX6  The default will build the module(s) located in the current
directory, so a target does not need to be specified. All
output files will also be generated in this directory. No
attempts are made to update the kernel source, and it is a
precondition that a successful â€œmakeâ€ has been executed for the
kernel.”…””}”(hjE  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kghj%  ubji  )”}”(hhh]”(jn  )”}”(hŒ…modules
The default target for external modules. It has the
same functionality as if no target was specified. See
description above.
”h]”(jt  )”}”(hŒmodules”h]”hŒmodules”…””}”(hjZ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´KqhjV  ubj„  )”}”(hhh]”hÌ)”}”(hŒ|The default target for external modules. It has the
same functionality as if no target was specified. See
description above.”h]”hŒ|The default target for external modules. It has the
same functionality as if no target was specified. See
description above.”…””}”(hjk  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kohjh  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hjV  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´KqhjS  ubjn  )”}”(hŒÏmodules_install
Install the external module(s). The default location is
/lib/modules/<kernel_release>/updates/, but a prefix may
be added with INSTALL_MOD_PATH (discussed in section
`Module Installation`_).
”h]”(jt  )”}”(hŒmodules_install”h]”hŒmodules_install”…””}”(hj‰  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´Kwhj…  ubj„  )”}”(hhh]”hÌ)”}”(hŒ¾Install the external module(s). The default location is
/lib/modules/<kernel_release>/updates/, but a prefix may
be added with INSTALL_MOD_PATH (discussed in section
`Module Installation`_).”h]”(hŒ¦Install the external module(s). The default location is
/lib/modules/<kernel_release>/updates/, but a prefix may
be added with INSTALL_MOD_PATH (discussed in section
”…””}”(hjš  h²hh³Nh´Nubj  )”}”(hŒ`Module Installation`_”h]”hŒModule Installation”…””}”(hj¢  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”Œname”ŒModule Installation”j  Œmodule-installation”uh1j  hjš  j  KubhŒ).”…””}”(hjš  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kthj—  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hj…  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´KwhjS  ubjn  )”}”(hŒ?clean
Remove all generated files in the module directory only.
”h]”(jt  )”}”(hŒclean”h]”hŒclean”…””}”(hjÍ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´KzhjÉ  ubj„  )”}”(hhh]”hÌ)”}”(hŒ8Remove all generated files in the module directory only.”h]”hŒ8Remove all generated files in the module directory only.”…””}”(hjÞ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KzhjÛ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hjÉ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´KzhjS  ubjn  )”}”(hŒ6help
List the available targets for external modules.
”h]”(jt  )”}”(hŒhelp”h]”hŒhelp”…””}”(hjü  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´K}hjø  ubj„  )”}”(hhh]”hÌ)”}”(hŒ0List the available targets for external modules.”h]”hŒ0List the available targets for external modules.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K}hj
  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hjø  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´K}hjS  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jh  hj%  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´Kbhj  h²hubeh}”(h]”Œtargets”ah ]”h"]”Œtargets”ah$]”h&]”uh1hµhj)  h²hh³hÊh´K`ubh¶)”}”(hhh]”(h»)”}”(hŒBuilding Separate Files”h]”hŒBuilding Separate Files”…””}”(hj>  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj;  h²hh³hÊh´K€ubjv  )”}”(hXZ  It is possible to build single files that are part of a module.
This works equally well for the kernel, a module, and even for
external modules.

Example (The module foo.ko, consist of bar.o and baz.o)::

        make -C $KDIR M=$PWD bar.lst
        make -C $KDIR M=$PWD baz.o
        make -C $KDIR M=$PWD foo.ko
        make -C $KDIR M=$PWD ./

”h]”(hÌ)”}”(hŒIt is possible to build single files that are part of a module.
This works equally well for the kernel, a module, and even for
external modules.”h]”hŒIt is possible to build single files that are part of a module.
This works equally well for the kernel, a module, and even for
external modules.”…””}”(hjP  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K‚hjL  ubhÌ)”}”(hŒ9Example (The module foo.ko, consist of bar.o and baz.o)::”h]”hŒ8Example (The module foo.ko, consist of bar.o and baz.o):”…””}”(hj^  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K†hjL  ubjŠ  )”}”(hŒkmake -C $KDIR M=$PWD bar.lst
make -C $KDIR M=$PWD baz.o
make -C $KDIR M=$PWD foo.ko
make -C $KDIR M=$PWD ./”h]”hŒkmake -C $KDIR M=$PWD bar.lst
make -C $KDIR M=$PWD baz.o
make -C $KDIR M=$PWD foo.ko
make -C $KDIR M=$PWD ./”…””}”hjl  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´KˆhjL  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´K‚hj;  h²hubeh}”(h]”Œbuilding-separate-files”ah ]”h"]”Œbuilding separate files”ah$]”h&]”uh1hµhj)  h²hh³hÊh´K€ubeh}”(h]”Œhow-to-build-external-modules”ah ]”h"]”Œhow to build external modules”ah$]”h&]”uh1hµhh·h²hh³hÊh´Kubh¶)”}”(hhh]”(h»)”}”(hŒ-Creating a Kbuild File for an External Module”h]”hŒ-Creating a Kbuild File for an External Module”…””}”(hj“  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj  h²hh³hÊh´KubhÌ)”}”(hX?  In the last section we saw the command to build a module for the
running kernel. The module is not actually built, however, because a
build file is required. Contained in this file will be the name of
the module(s) being built, along with the list of requisite source
files. The file may be as simple as a single line::”h]”hX>  In the last section we saw the command to build a module for the
running kernel. The module is not actually built, however, because a
build file is required. Contained in this file will be the name of
the module(s) being built, along with the list of requisite source
files. The file may be as simple as a single line:”…””}”(hj¡  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K‘hj  h²hubjŠ  )”}”(hŒobj-m := <module_name>.o”h]”hŒobj-m := <module_name>.o”…””}”hj¯  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´K—hj  h²hubhÌ)”}”(hX/  The kbuild system will build <module_name>.o from <module_name>.c,
and, after linking, will result in the kernel module <module_name>.ko.
The above line can be put in either a "Kbuild" file or a "Makefile."
When the module is built from multiple sources, an additional line is
needed listing the files::”h]”hX6  The kbuild system will build <module_name>.o from <module_name>.c,
and, after linking, will result in the kernel module <module_name>.ko.
The above line can be put in either a â€œKbuildâ€ file or a â€œMakefile.â€
When the module is built from multiple sources, an additional line is
needed listing the files:”…””}”(hj½  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K™hj  h²hubjŠ  )”}”(hŒ(<module_name>-y := <src1>.o <src2>.o ...”h]”hŒ(<module_name>-y := <src1>.o <src2>.o ...”…””}”hjË  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´KŸhj  h²hubhÌ)”}”(hŒrNOTE: Further documentation describing the syntax used by kbuild is
located in Documentation/kbuild/makefiles.rst.”h]”hŒrNOTE: Further documentation describing the syntax used by kbuild is
located in Documentation/kbuild/makefiles.rst.”…””}”(hjÙ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K¡hj  h²hubhÌ)”}”(hŒ{The examples below demonstrate how to create a build file for the
module 8123.ko, which is built from the following files::”h]”hŒzThe examples below demonstrate how to create a build file for the
module 8123.ko, which is built from the following files:”…””}”(hjç  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K¤hj  h²hubjŠ  )”}”(hŒ8123_if.c
8123_if.h
8123_pci.c”h]”hŒ8123_if.c
8123_if.h
8123_pci.c”…””}”hjõ  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´K§hj  h²hubh¶)”}”(hhh]”(h»)”}”(hŒShared Makefile”h]”hŒShared Makefile”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj  h²hh³hÊh´K¬ubjv  )”}”(hX7  An external module always includes a wrapper makefile that
supports building the module using "make" with no arguments.
This target is not used by kbuild; it is only for convenience.
Additional functionality, such as test targets, can be included
but should be filtered out from kbuild due to possible name
clashes.

Example 1::

        --> filename: Makefile
        ifneq ($(KERNELRELEASE),)
        # kbuild part of makefile
        obj-m  := 8123.o
        8123-y := 8123_if.o 8123_pci.o

        else
        # normal makefile
        KDIR ?= /lib/modules/`uname -r`/build

        default:
                $(MAKE) -C $(KDIR) M=$$PWD

        endif

The check for KERNELRELEASE is used to separate the two parts
of the makefile. In the example, kbuild will only see the two
assignments, whereas "make" will see everything except these
two assignments. This is due to two passes made on the file:
the first pass is by the "make" instance run on the command
line; the second pass is by the kbuild system, which is
initiated by the parameterized "make" in the default target.
”h]”(hÌ)”}”(hX;  An external module always includes a wrapper makefile that
supports building the module using "make" with no arguments.
This target is not used by kbuild; it is only for convenience.
Additional functionality, such as test targets, can be included
but should be filtered out from kbuild due to possible name
clashes.”h]”hX?  An external module always includes a wrapper makefile that
supports building the module using â€œmakeâ€ with no arguments.
This target is not used by kbuild; it is only for convenience.
Additional functionality, such as test targets, can be included
but should be filtered out from kbuild due to possible name
clashes.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´K®hj  ubhÌ)”}”(hŒExample 1::”h]”hŒ
Example 1:”…””}”(hj&  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kµhj  ubjŠ  )”}”(hŒì--> filename: Makefile
ifneq ($(KERNELRELEASE),)
# kbuild part of makefile
obj-m  := 8123.o
8123-y := 8123_if.o 8123_pci.o

else
# normal makefile
KDIR ?= /lib/modules/`uname -r`/build

default:
        $(MAKE) -C $(KDIR) M=$$PWD

endif”h]”hŒì--> filename: Makefile
ifneq ($(KERNELRELEASE),)
# kbuild part of makefile
obj-m  := 8123.o
8123-y := 8123_if.o 8123_pci.o

else
# normal makefile
KDIR ?= /lib/modules/`uname -r`/build

default:
        $(MAKE) -C $(KDIR) M=$$PWD

endif”…””}”hj4  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´K·hj  ubhÌ)”}”(hX¦  The check for KERNELRELEASE is used to separate the two parts
of the makefile. In the example, kbuild will only see the two
assignments, whereas "make" will see everything except these
two assignments. This is due to two passes made on the file:
the first pass is by the "make" instance run on the command
line; the second pass is by the kbuild system, which is
initiated by the parameterized "make" in the default target.”h]”hX²  The check for KERNELRELEASE is used to separate the two parts
of the makefile. In the example, kbuild will only see the two
assignments, whereas â€œmakeâ€ will see everything except these
two assignments. This is due to two passes made on the file:
the first pass is by the â€œmakeâ€ instance run on the command
line; the second pass is by the kbuild system, which is
initiated by the parameterized â€œmakeâ€ in the default target.”…””}”(hjB  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÆhj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´K®hj  h²hubeh}”(h]”Œshared-makefile”ah ]”h"]”Œshared makefile”ah$]”h&]”uh1hµhj  h²hh³hÊh´K¬ubh¶)”}”(hhh]”(h»)”}”(hŒ!Separate Kbuild File and Makefile”h]”hŒ!Separate Kbuild File and Makefile”…””}”(hja  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj^  h²hh³hÊh´KÏubjv  )”}”(hXh  Kbuild will first look for a file named "Kbuild", and if it is not
found, it will then look for "Makefile". Utilizing a "Kbuild" file
allows us to split up the "Makefile" from example 1 into two files:

Example 2::

        --> filename: Kbuild
        obj-m  := 8123.o
        8123-y := 8123_if.o 8123_pci.o

        --> filename: Makefile
        KDIR ?= /lib/modules/`uname -r`/build

        default:
                $(MAKE) -C $(KDIR) M=$$PWD

The split in example 2 is questionable due to the simplicity of
each file; however, some external modules use makefiles
consisting of several hundred lines, and here it really pays
off to separate the kbuild part from the rest.

Linux 6.13 and later support another way. The external module Makefile
can include the kernel Makefile directly, rather than invoking sub Make.

Example 3::

        --> filename: Kbuild
        obj-m  := 8123.o
        8123-y := 8123_if.o 8123_pci.o

        --> filename: Makefile
        KDIR ?= /lib/modules/$(shell uname -r)/build
        export KBUILD_EXTMOD := $(realpath $(dir $(lastword $(MAKEFILE_LIST))))
        include $(KDIR)/Makefile

”h]”(hÌ)”}”(hŒÉKbuild will first look for a file named "Kbuild", and if it is not
found, it will then look for "Makefile". Utilizing a "Kbuild" file
allows us to split up the "Makefile" from example 1 into two files:”h]”hŒÙKbuild will first look for a file named â€œKbuildâ€, and if it is not
found, it will then look for â€œMakefileâ€. Utilizing a â€œKbuildâ€ file
allows us to split up the â€œMakefileâ€ from example 1 into two files:”…””}”(hjs  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÑhjo  ubhÌ)”}”(hŒExample 2::”h]”hŒ
Example 2:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´KÕhjo  ubjŠ  )”}”(hŒ¯--> filename: Kbuild
obj-m  := 8123.o
8123-y := 8123_if.o 8123_pci.o

--> filename: Makefile
KDIR ?= /lib/modules/`uname -r`/build

default:
        $(MAKE) -C $(KDIR) M=$$PWD”h]”hŒ¯--> filename: Kbuild
obj-m  := 8123.o
8123-y := 8123_if.o 8123_pci.o

--> filename: Makefile
KDIR ?= /lib/modules/`uname -r`/build

default:
        $(MAKE) -C $(KDIR) M=$$PWD”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´K×hjo  ubhÌ)”}”(hŒãThe split in example 2 is questionable due to the simplicity of
each file; however, some external modules use makefiles
consisting of several hundred lines, and here it really pays
off to separate the kbuild part from the rest.”h]”hŒãThe split in example 2 is questionable due to the simplicity of
each file; however, some external modules use makefiles
consisting of several hundred lines, and here it really pays
off to separate the kbuild part from the rest.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Káhjo  ubhÌ)”}”(hŒLinux 6.13 and later support another way. The external module Makefile
can include the kernel Makefile directly, rather than invoking sub Make.”h]”hŒLinux 6.13 and later support another way. The external module Makefile
can include the kernel Makefile directly, rather than invoking sub Make.”…””}”(hj«  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kæhjo  ubhÌ)”}”(hŒExample 3::”h]”hŒ
Example 3:”…””}”(hj¹  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Kéhjo  ubjŠ  )”}”(hŒê--> filename: Kbuild
obj-m  := 8123.o
8123-y := 8123_if.o 8123_pci.o

--> filename: Makefile
KDIR ?= /lib/modules/$(shell uname -r)/build
export KBUILD_EXTMOD := $(realpath $(dir $(lastword $(MAKEFILE_LIST))))
include $(KDIR)/Makefile”h]”hŒê--> filename: Kbuild
obj-m  := 8123.o
8123-y := 8123_if.o 8123_pci.o

--> filename: Makefile
KDIR ?= /lib/modules/$(shell uname -r)/build
export KBUILD_EXTMOD := $(realpath $(dir $(lastword $(MAKEFILE_LIST))))
include $(KDIR)/Makefile”…””}”hjÇ  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´Këhjo  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´KÑhj^  h²hubeh}”(h]”Œ!separate-kbuild-file-and-makefile”ah ]”h"]”Œ!separate kbuild file and makefile”ah$]”h&]”uh1hµhj  h²hh³hÊh´KÏubh¶)”}”(hhh]”(h»)”}”(hŒBuilding Multiple Modules”h]”hŒBuilding Multiple Modules”…””}”(hjæ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjã  h²hh³hÊh´Köubjv  )”}”(hX  kbuild supports building multiple modules with a single build
file. For example, if you wanted to build two modules, foo.ko
and bar.ko, the kbuild lines would be::

        obj-m := foo.o bar.o
        foo-y := <foo_srcs>
        bar-y := <bar_srcs>

It is that simple!

”h]”(hÌ)”}”(hŒ£kbuild supports building multiple modules with a single build
file. For example, if you wanted to build two modules, foo.ko
and bar.ko, the kbuild lines would be::”h]”hŒ¢kbuild supports building multiple modules with a single build
file. For example, if you wanted to build two modules, foo.ko
and bar.ko, the kbuild lines would be:”…””}”(hjø  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Køhjô  ubjŠ  )”}”(hŒ<obj-m := foo.o bar.o
foo-y := <foo_srcs>
bar-y := <bar_srcs>”h]”hŒ<obj-m := foo.o bar.o
foo-y := <foo_srcs>
bar-y := <bar_srcs>”…””}”hj  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´Kühjô  ubhÌ)”}”(hŒIt is that simple!”h]”hŒIt is that simple!”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M hjô  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´Køhjã  h²hubeh}”(h]”Œbuilding-multiple-modules”ah ]”h"]”Œbuilding multiple modules”ah$]”h&]”uh1hµhj  h²hh³hÊh´Köubeh}”(h]”j  ah ]”h"]”Œ-creating a kbuild file for an external module”ah$]”h&]”uh1hµhh·h²hh³hÊh´KŒ
referenced”Kubh¶)”}”(hhh]”(h»)”}”(hŒInclude Files”h]”hŒInclude Files”…””}”(hj;  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj8  h²hh³hÊh´MubhÌ)”}”(hŒ_Within the kernel, header files are kept in standard locations
according to the following rule:”h]”hŒ_Within the kernel, header files are kept in standard locations
according to the following rule:”…””}”(hjI  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhj8  h²hubjv  )”}”(hX&  * If the header file only describes the internal interface of a
  module, then the file is placed in the same directory as the
  source files.
* If the header file describes an interface used by other parts
  of the kernel that are located in different directories, then
  the file is placed in include/linux/.

  NOTE:
      There are two notable exceptions to this rule: larger
      subsystems have their own directory under include/, such as
      include/scsi; and architecture specific headers are located
      under arch/$(SRCARCH)/include/.
”h]”hŒbullet_list”“”)”}”(hhh]”(hŒ	list_item”“”)”}”(hŒˆIf the header file only describes the internal interface of a
module, then the file is placed in the same directory as the
source files.”h]”hÌ)”}”(hŒˆIf the header file only describes the internal interface of a
module, then the file is placed in the same directory as the
source files.”h]”hŒˆIf the header file only describes the internal interface of a
module, then the file is placed in the same directory as the
source files.”…””}”(hjf  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M	hjb  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j`  hj]  ubja  )”}”(hX‡  If the header file describes an interface used by other parts
of the kernel that are located in different directories, then
the file is placed in include/linux/.

NOTE:
    There are two notable exceptions to this rule: larger
    subsystems have their own directory under include/, such as
    include/scsi; and architecture specific headers are located
    under arch/$(SRCARCH)/include/.
”h]”(hÌ)”}”(hŒ¡If the header file describes an interface used by other parts
of the kernel that are located in different directories, then
the file is placed in include/linux/.”h]”hŒ¡If the header file describes an interface used by other parts
of the kernel that are located in different directories, then
the file is placed in include/linux/.”…””}”(hj~  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjz  ubji  )”}”(hhh]”jn  )”}”(hŒÔNOTE:
There are two notable exceptions to this rule: larger
subsystems have their own directory under include/, such as
include/scsi; and architecture specific headers are located
under arch/$(SRCARCH)/include/.
”h]”(jt  )”}”(hŒNOTE:”h]”hŒNOTE:”…””}”(hj“  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´Mhj  ubj„  )”}”(hhh]”hÌ)”}”(hŒÍThere are two notable exceptions to this rule: larger
subsystems have their own directory under include/, such as
include/scsi; and architecture specific headers are located
under arch/$(SRCARCH)/include/.”h]”hŒÍThere are two notable exceptions to this rule: larger
subsystems have their own directory under include/, such as
include/scsi; and architecture specific headers are located
under arch/$(SRCARCH)/include/.”…””}”(hj¤  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhj¡  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´MhjŒ  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jh  hjz  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1j`  hj]  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ*”uh1j[  h³hÊh´M	hjW  ubah}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´M	hj8  h²hubh¶)”}”(hhh]”(h»)”}”(hŒKernel Includes”h]”hŒKernel Includes”…””}”(hjÛ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjØ  h²hh³hÊh´Mubjv  )”}”(hŒºTo include a header file located under include/linux/, simply
use::

        #include <linux/module.h>

kbuild will add options to the compiler so the relevant directories
are searched.
”h]”(hÌ)”}”(hŒCTo include a header file located under include/linux/, simply
use::”h]”hŒBTo include a header file located under include/linux/, simply
use:”…””}”(hjí  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjé  ubjŠ  )”}”(hŒ#include <linux/module.h>”h]”hŒ#include <linux/module.h>”…””}”hjû  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´Mhjé  ubhÌ)”}”(hŒQkbuild will add options to the compiler so the relevant directories
are searched.”h]”hŒQkbuild will add options to the compiler so the relevant directories
are searched.”…””}”(hj	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mhjé  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´MhjØ  h²hubeh}”(h]”Œkernel-includes”ah ]”h"]”Œkernel includes”ah$]”h&]”uh1hµhj8  h²hh³hÊh´Mubh¶)”}”(hhh]”(h»)”}”(hŒSingle Subdirectory”h]”hŒSingle Subdirectory”…””}”(hj(  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj%  h²hh³hÊh´M"ubjv  )”}”(hXô  External modules tend to place header files in a separate
include/ directory where their source is located, although this
is not the usual kernel style. To inform kbuild of the
directory, use either ccflags-y or CFLAGS_<filename>.o.

Using the example from section 3, if we moved 8123_if.h to a
subdirectory named include, the resulting kbuild file would
look like::

        --> filename: Kbuild
        obj-m := 8123.o

        ccflags-y := -I $(src)/include
        8123-y := 8123_if.o 8123_pci.o
”h]”(hÌ)”}”(hŒèExternal modules tend to place header files in a separate
include/ directory where their source is located, although this
is not the usual kernel style. To inform kbuild of the
directory, use either ccflags-y or CFLAGS_<filename>.o.”h]”hŒèExternal modules tend to place header files in a separate
include/ directory where their source is located, although this
is not the usual kernel style. To inform kbuild of the
directory, use either ccflags-y or CFLAGS_<filename>.o.”…””}”(hj:  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M$hj6  ubhÌ)”}”(hŒ„Using the example from section 3, if we moved 8123_if.h to a
subdirectory named include, the resulting kbuild file would
look like::”h]”hŒƒUsing the example from section 3, if we moved 8123_if.h to a
subdirectory named include, the resulting kbuild file would
look like:”…””}”(hjH  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M)hj6  ubjŠ  )”}”(hŒc--> filename: Kbuild
obj-m := 8123.o

ccflags-y := -I $(src)/include
8123-y := 8123_if.o 8123_pci.o”h]”hŒc--> filename: Kbuild
obj-m := 8123.o

ccflags-y := -I $(src)/include
8123-y := 8123_if.o 8123_pci.o”…””}”hjV  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´M-hj6  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´M$hj%  h²hubeh}”(h]”Œsingle-subdirectory”ah ]”h"]”Œsingle subdirectory”ah$]”h&]”uh1hµhj8  h²hh³hÊh´M"ubh¶)”}”(hhh]”(h»)”}”(hŒSeveral Subdirectories”h]”hŒSeveral Subdirectories”…””}”(hju  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjr  h²hh³hÊh´M4ubjv  )”}”(hX•  kbuild can handle files that are spread over several directories.
Consider the following example::

        .
        |__ src
        |   |__ complex_main.c
        |   |__ hal
        |       |__ hardwareif.c
        |       |__ include
        |           |__ hardwareif.h
        |__ include
                |__ complex.h

To build the module complex.ko, we then need the following
kbuild file::

        --> filename: Kbuild
        obj-m := complex.o
        complex-y := src/complex_main.o
        complex-y += src/hal/hardwareif.o

        ccflags-y := -I$(src)/include
        ccflags-y += -I$(src)/src/hal/include

As you can see, kbuild knows how to handle object files located
in other directories. The trick is to specify the directory
relative to the kbuild file's location. That being said, this
is NOT recommended practice.

For the header files, kbuild must be explicitly told where to
look. When kbuild executes, the current directory is always the
root of the kernel tree (the argument to "-C") and therefore an
absolute path is needed. $(src) provides the absolute path by
pointing to the directory where the currently executing kbuild
file is located.

”h]”(hÌ)”}”(hŒbkbuild can handle files that are spread over several directories.
Consider the following example::”h]”hŒakbuild can handle files that are spread over several directories.
Consider the following example:”…””}”(hj‡  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M6hjƒ  ubjŠ  )”}”(hŒ˜.
|__ src
|   |__ complex_main.c
|   |__ hal
|       |__ hardwareif.c
|       |__ include
|           |__ hardwareif.h
|__ include
        |__ complex.h”h]”hŒ˜.
|__ src
|   |__ complex_main.c
|   |__ hal
|       |__ hardwareif.c
|       |__ include
|           |__ hardwareif.h
|__ include
        |__ complex.h”…””}”hj•  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´M9hjƒ  ubhÌ)”}”(hŒHTo build the module complex.ko, we then need the following
kbuild file::”h]”hŒGTo build the module complex.ko, we then need the following
kbuild file:”…””}”(hj£  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MChjƒ  ubjŠ  )”}”(hŒ®--> filename: Kbuild
obj-m := complex.o
complex-y := src/complex_main.o
complex-y += src/hal/hardwareif.o

ccflags-y := -I$(src)/include
ccflags-y += -I$(src)/src/hal/include”h]”hŒ®--> filename: Kbuild
obj-m := complex.o
complex-y := src/complex_main.o
complex-y += src/hal/hardwareif.o

ccflags-y := -I$(src)/include
ccflags-y += -I$(src)/src/hal/include”…””}”hj±  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´MFhjƒ  ubhÌ)”}”(hŒÖAs you can see, kbuild knows how to handle object files located
in other directories. The trick is to specify the directory
relative to the kbuild file's location. That being said, this
is NOT recommended practice.”h]”hŒØAs you can see, kbuild knows how to handle object files located
in other directories. The trick is to specify the directory
relative to the kbuild fileâ€™s location. That being said, this
is NOT recommended practice.”…””}”(hj¿  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MNhjƒ  ubhÌ)”}”(hXK  For the header files, kbuild must be explicitly told where to
look. When kbuild executes, the current directory is always the
root of the kernel tree (the argument to "-C") and therefore an
absolute path is needed. $(src) provides the absolute path by
pointing to the directory where the currently executing kbuild
file is located.”h]”hXO  For the header files, kbuild must be explicitly told where to
look. When kbuild executes, the current directory is always the
root of the kernel tree (the argument to â€œ-Câ€) and therefore an
absolute path is needed. $(src) provides the absolute path by
pointing to the directory where the currently executing kbuild
file is located.”…””}”(hjÍ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MShjƒ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´M6hjr  h²hubeh}”(h]”Œseveral-subdirectories”ah ]”h"]”Œseveral subdirectories”ah$]”h&]”uh1hµhj8  h²hh³hÊh´M4ubeh}”(h]”Œinclude-files”ah ]”h"]”Œinclude files”ah$]”h&]”uh1hµhh·h²hh³hÊh´Mubh¶)”}”(hhh]”(h»)”}”(hŒModule Installation”h]”hŒModule Installation”…””}”(hjô  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjñ  h²hh³hÊh´M\ubhÌ)”}”(hŒHModules which are included in the kernel are installed in the
directory:”h]”hŒHModules which are included in the kernel are installed in the
directory:”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M^hjñ  h²hubjv  )”}”(hŒ&/lib/modules/$(KERNELRELEASE)/kernel/
”h]”hÌ)”}”(hŒ%/lib/modules/$(KERNELRELEASE)/kernel/”h]”hŒ%/lib/modules/$(KERNELRELEASE)/kernel/”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mahj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´Mahjñ  h²hubhÌ)”}”(hŒ&And external modules are installed in:”h]”hŒ&And external modules are installed in:”…””}”(hj(  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mchjñ  h²hubjv  )”}”(hŒ'/lib/modules/$(KERNELRELEASE)/updates/
”h]”hÌ)”}”(hŒ&/lib/modules/$(KERNELRELEASE)/updates/”h]”hŒ&/lib/modules/$(KERNELRELEASE)/updates/”…””}”(hj:  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mehj6  ubah}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´Mehjñ  h²hubh¶)”}”(hhh]”(h»)”}”(hŒINSTALL_MOD_PATH”h]”hŒINSTALL_MOD_PATH”…””}”(hjQ  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjN  h²hh³hÊh´Mhubjv  )”}”(hXù  Above are the default directories but as always some level of
customization is possible. A prefix can be added to the
installation path using the variable INSTALL_MOD_PATH::

        $ make INSTALL_MOD_PATH=/frodo modules_install
        => Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel/

INSTALL_MOD_PATH may be set as an ordinary shell variable or,
as shown above, can be specified on the command line when
calling "make." This has effect when installing both in-tree
and out-of-tree modules.
”h]”(hÌ)”}”(hŒ­Above are the default directories but as always some level of
customization is possible. A prefix can be added to the
installation path using the variable INSTALL_MOD_PATH::”h]”hŒ¬Above are the default directories but as always some level of
customization is possible. A prefix can be added to the
installation path using the variable INSTALL_MOD_PATH:”…””}”(hjc  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mjhj_  ubjŠ  )”}”(hŒj$ make INSTALL_MOD_PATH=/frodo modules_install
=> Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel/”h]”hŒj$ make INSTALL_MOD_PATH=/frodo modules_install
=> Install dir: /frodo/lib/modules/$(KERNELRELEASE)/kernel/”…””}”hjq  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´Mnhj_  ubhÌ)”}”(hŒÍINSTALL_MOD_PATH may be set as an ordinary shell variable or,
as shown above, can be specified on the command line when
calling "make." This has effect when installing both in-tree
and out-of-tree modules.”h]”hŒÑINSTALL_MOD_PATH may be set as an ordinary shell variable or,
as shown above, can be specified on the command line when
calling â€œmake.â€ This has effect when installing both in-tree
and out-of-tree modules.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mqhj_  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´MjhjN  h²hubeh}”(h]”Œinstall-mod-path”ah ]”h"]”Œinstall_mod_path”ah$]”h&]”uh1hµhjñ  h²hh³hÊh´Mhubh¶)”}”(hhh]”(h»)”}”(hŒINSTALL_MOD_DIR”h]”hŒINSTALL_MOD_DIR”…””}”(hjž  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj›  h²hh³hÊh´Mwubjv  )”}”(hX®  External modules are by default installed to a directory under
/lib/modules/$(KERNELRELEASE)/updates/, but you may wish to
locate modules for a specific functionality in a separate
directory. For this purpose, use INSTALL_MOD_DIR to specify an
alternative name to "updates."::

        $ make INSTALL_MOD_DIR=gandalf -C $KDIR \
               M=$PWD modules_install
        => Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/

”h]”(hÌ)”}”(hX  External modules are by default installed to a directory under
/lib/modules/$(KERNELRELEASE)/updates/, but you may wish to
locate modules for a specific functionality in a separate
directory. For this purpose, use INSTALL_MOD_DIR to specify an
alternative name to "updates."::”h]”hX  External modules are by default installed to a directory under
/lib/modules/$(KERNELRELEASE)/updates/, but you may wish to
locate modules for a specific functionality in a separate
directory. For this purpose, use INSTALL_MOD_DIR to specify an
alternative name to â€œupdates.â€:”…””}”(hj°  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Myhj¬  ubjŠ  )”}”(hŒ~$ make INSTALL_MOD_DIR=gandalf -C $KDIR \
       M=$PWD modules_install
=> Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/”h]”hŒ~$ make INSTALL_MOD_DIR=gandalf -C $KDIR \
       M=$PWD modules_install
=> Install dir: /lib/modules/$(KERNELRELEASE)/gandalf/”…””}”hj¾  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´Mhj¬  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´Myhj›  h²hubeh}”(h]”Œinstall-mod-dir”ah ]”h"]”Œinstall_mod_dir”ah$]”h&]”uh1hµhjñ  h²hh³hÊh´Mwubeh}”(h]”j²  ah ]”h"]”Œmodule installation”ah$]”h&]”uh1hµhh·h²hh³hÊh´M\j7  Kubh¶)”}”(hhh]”(h»)”}”(hŒModule Versioning”h]”hŒModule Versioning”…””}”(hjä  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjá  h²hh³hÊh´M…ubhÌ)”}”(hXb  Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used
as a simple ABI consistency check. A CRC value of the full prototype
for an exported symbol is created. When a module is loaded/used, the
CRC values contained in the kernel are compared with similar values in
the module; if they are not equal, the kernel refuses to load the
module.”h]”hXb  Module versioning is enabled by the CONFIG_MODVERSIONS tag, and is used
as a simple ABI consistency check. A CRC value of the full prototype
for an exported symbol is created. When a module is loaded/used, the
CRC values contained in the kernel are compared with similar values in
the module; if they are not equal, the kernel refuses to load the
module.”…””}”(hjò  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M‡hjá  h²hubhÌ)”}”(hŒKModule.symvers contains a list of all exported symbols from a kernel
build.”h]”hŒKModule.symvers contains a list of all exported symbols from a kernel
build.”…””}”(hj 	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MŽhjá  h²hubh¶)”}”(hhh]”(h»)”}”(hŒ+Symbols From the Kernel (vmlinux + modules)”h]”hŒ+Symbols From the Kernel (vmlinux + modules)”…””}”(hj	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj	  h²hh³hÊh´M’ubjv  )”}”(hX2  During a kernel build, a file named Module.symvers will be
generated. Module.symvers contains all exported symbols from
the kernel and compiled modules. For each symbol, the
corresponding CRC value is also stored.

The syntax of the Module.symvers file is::

        <CRC>       <Symbol>         <Module>                         <Export Type>     <Namespace>

        0xe1cc2a05  usb_stor_suspend drivers/usb/storage/usb-storage  EXPORT_SYMBOL_GPL USB_STORAGE

The fields are separated by tabs and values may be empty (e.g.
if no namespace is defined for an exported symbol).

For a kernel build without CONFIG_MODVERSIONS enabled, the CRC
would read 0x00000000.

Module.symvers serves two purposes:

1) It lists all exported symbols from vmlinux and all modules.
2) It lists the CRC if CONFIG_MODVERSIONS is enabled.
”h]”(hÌ)”}”(hŒÕDuring a kernel build, a file named Module.symvers will be
generated. Module.symvers contains all exported symbols from
the kernel and compiled modules. For each symbol, the
corresponding CRC value is also stored.”h]”hŒÕDuring a kernel build, a file named Module.symvers will be
generated. Module.symvers contains all exported symbols from
the kernel and compiled modules. For each symbol, the
corresponding CRC value is also stored.”…””}”(hj#	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M”hj	  ubhÌ)”}”(hŒ*The syntax of the Module.symvers file is::”h]”hŒ)The syntax of the Module.symvers file is:”…””}”(hj1	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M™hj	  ubjŠ  )”}”(hŒ¸<CRC>       <Symbol>         <Module>                         <Export Type>     <Namespace>

0xe1cc2a05  usb_stor_suspend drivers/usb/storage/usb-storage  EXPORT_SYMBOL_GPL USB_STORAGE”h]”hŒ¸<CRC>       <Symbol>         <Module>                         <Export Type>     <Namespace>

0xe1cc2a05  usb_stor_suspend drivers/usb/storage/usb-storage  EXPORT_SYMBOL_GPL USB_STORAGE”…””}”hj?	  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´M›hj	  ubhÌ)”}”(hŒrThe fields are separated by tabs and values may be empty (e.g.
if no namespace is defined for an exported symbol).”h]”hŒrThe fields are separated by tabs and values may be empty (e.g.
if no namespace is defined for an exported symbol).”…””}”(hjM	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MŸhj	  ubhÌ)”}”(hŒUFor a kernel build without CONFIG_MODVERSIONS enabled, the CRC
would read 0x00000000.”h]”hŒUFor a kernel build without CONFIG_MODVERSIONS enabled, the CRC
would read 0x00000000.”…””}”(hj[	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M¢hj	  ubhÌ)”}”(hŒ#Module.symvers serves two purposes:”h]”hŒ#Module.symvers serves two purposes:”…””}”(hji	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M¥hj	  ubhŒenumerated_list”“”)”}”(hhh]”(ja  )”}”(hŒ;It lists all exported symbols from vmlinux and all modules.”h]”hÌ)”}”(hj~	  h]”hŒ;It lists all exported symbols from vmlinux and all modules.”…””}”(hj€	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M§hj|	  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j`  hjy	  ubja  )”}”(hŒ3It lists the CRC if CONFIG_MODVERSIONS is enabled.
”h]”hÌ)”}”(hŒ2It lists the CRC if CONFIG_MODVERSIONS is enabled.”h]”hŒ2It lists the CRC if CONFIG_MODVERSIONS is enabled.”…””}”(hj—	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M¨hj“	  ubah}”(h]”h ]”h"]”h$]”h&]”uh1j`  hjy	  ubeh}”(h]”h ]”h"]”h$]”h&]”Œenumtype”Œarabic”Œprefix”hŒsuffix”Œ)”uh1jw	  hj	  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´M”hj	  h²hubeh}”(h]”Œ'symbols-from-the-kernel-vmlinux-modules”ah ]”h"]”Œ+symbols from the kernel (vmlinux + modules)”ah$]”h&]”uh1hµhjá  h²hh³hÊh´M’ubh¶)”}”(hhh]”(h»)”}”(hŒVersion Information Formats”h]”hŒVersion Information Formats”…””}”(hjÇ	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjÄ	  h²hh³hÊh´M«ubjv  )”}”(hX  Exported symbols have information stored in the __ksymtab and
__kflagstab sections. Symbol names and namespaces are stored in
__ksymtab_strings section, using a format similar to the string
table used for ELF. If CONFIG_MODVERSIONS is enabled, the CRCs
corresponding to exported symbols will be added to the
__kcrctab section.

If CONFIG_BASIC_MODVERSIONS is enabled (default with
CONFIG_MODVERSIONS), imported symbols will have their symbol name and
CRC stored in the __versions section of the importing module. This
mode only supports symbols of length up to 64 bytes.

If CONFIG_EXTENDED_MODVERSIONS is enabled (required to enable both
CONFIG_MODVERSIONS and CONFIG_RUST at the same time), imported symbols
will have their symbol name recorded in the __version_ext_names
section as a series of concatenated, null-terminated strings. CRCs for
these symbols will be recorded in the __version_ext_crcs section.
”h]”(hÌ)”}”(hXF  Exported symbols have information stored in the __ksymtab and
__kflagstab sections. Symbol names and namespaces are stored in
__ksymtab_strings section, using a format similar to the string
table used for ELF. If CONFIG_MODVERSIONS is enabled, the CRCs
corresponding to exported symbols will be added to the
__kcrctab section.”h]”hXF  Exported symbols have information stored in the __ksymtab and
__kflagstab sections. Symbol names and namespaces are stored in
__ksymtab_strings section, using a format similar to the string
table used for ELF. If CONFIG_MODVERSIONS is enabled, the CRCs
corresponding to exported symbols will be added to the
__kcrctab section.”…””}”(hjÙ	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M­hjÕ	  ubhÌ)”}”(hŒòIf CONFIG_BASIC_MODVERSIONS is enabled (default with
CONFIG_MODVERSIONS), imported symbols will have their symbol name and
CRC stored in the __versions section of the importing module. This
mode only supports symbols of length up to 64 bytes.”h]”hŒòIf CONFIG_BASIC_MODVERSIONS is enabled (default with
CONFIG_MODVERSIONS), imported symbols will have their symbol name and
CRC stored in the __versions section of the importing module. This
mode only supports symbols of length up to 64 bytes.”…””}”(hjç	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M´hjÕ	  ubhÌ)”}”(hXR  If CONFIG_EXTENDED_MODVERSIONS is enabled (required to enable both
CONFIG_MODVERSIONS and CONFIG_RUST at the same time), imported symbols
will have their symbol name recorded in the __version_ext_names
section as a series of concatenated, null-terminated strings. CRCs for
these symbols will be recorded in the __version_ext_crcs section.”h]”hXR  If CONFIG_EXTENDED_MODVERSIONS is enabled (required to enable both
CONFIG_MODVERSIONS and CONFIG_RUST at the same time), imported symbols
will have their symbol name recorded in the __version_ext_names
section as a series of concatenated, null-terminated strings. CRCs for
these symbols will be recorded in the __version_ext_crcs section.”…””}”(hjõ	  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´M¹hjÕ	  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´M­hjÄ	  h²hubeh}”(h]”Œversion-information-formats”ah ]”h"]”Œversion information formats”ah$]”h&]”uh1hµhjá  h²hh³hÊh´M«ubh¶)”}”(hhh]”(h»)”}”(hŒSymbols and External Modules”h]”hŒSymbols and External Modules”…””}”(hj
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhj
  h²hh³hÊh´MÀubjv  )”}”(hX€  When building an external module, the build system needs access
to the symbols from the kernel to check if all external symbols
are defined. This is done in the MODPOST step. modpost obtains
the symbols by reading Module.symvers from the kernel source
tree. During the MODPOST step, a new Module.symvers file will be
written containing all exported symbols from that external module.
”h]”hÌ)”}”(hX  When building an external module, the build system needs access
to the symbols from the kernel to check if all external symbols
are defined. This is done in the MODPOST step. modpost obtains
the symbols by reading Module.symvers from the kernel source
tree. During the MODPOST step, a new Module.symvers file will be
written containing all exported symbols from that external module.”h]”hX  When building an external module, the build system needs access
to the symbols from the kernel to check if all external symbols
are defined. This is done in the MODPOST step. modpost obtains
the symbols by reading Module.symvers from the kernel source
tree. During the MODPOST step, a new Module.symvers file will be
written containing all exported symbols from that external module.”…””}”(hj&
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÂhj"
  ubah}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´MÂhj
  h²hubeh}”(h]”Œsymbols-and-external-modules”ah ]”h"]”Œsymbols and external modules”ah$]”h&]”uh1hµhjá  h²hh³hÊh´MÀubh¶)”}”(hhh]”(h»)”}”(hŒ$Symbols From Another External Module”h]”hŒ$Symbols From Another External Module”…””}”(hjE
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjB
  h²hh³hÊh´MÊubjv  )”}”(hXF  Sometimes, an external module uses exported symbols from
another external module. Kbuild needs to have full knowledge of
all symbols to avoid spitting out warnings about undefined
symbols. Two solutions exist for this situation.

NOTE: The method with a top-level kbuild file is recommended
but may be impractical in certain situations.

Use a top-level kbuild file
        If you have two modules, foo.ko and bar.ko, where
        foo.ko needs symbols from bar.ko, you can use a
        common top-level kbuild file so both modules are
        compiled in the same build. Consider the following
        directory layout::

                ./foo/ <= contains foo.ko
                ./bar/ <= contains bar.ko

        The top-level kbuild file would then look like::

                #./Kbuild (or ./Makefile):
                        obj-m := foo/ bar/

        And executing::

                $ make -C $KDIR M=$PWD

        will then do the expected and compile both modules with
        full knowledge of symbols from either module.

Use "make" variable KBUILD_EXTRA_SYMBOLS
        If it is impractical to add a top-level kbuild file,
        you can assign a space separated list
        of files to KBUILD_EXTRA_SYMBOLS in your build file.
        These files will be loaded by modpost during the
        initialization of its symbol tables.

”h]”(hÌ)”}”(hŒäSometimes, an external module uses exported symbols from
another external module. Kbuild needs to have full knowledge of
all symbols to avoid spitting out warnings about undefined
symbols. Two solutions exist for this situation.”h]”hŒäSometimes, an external module uses exported symbols from
another external module. Kbuild needs to have full knowledge of
all symbols to avoid spitting out warnings about undefined
symbols. Two solutions exist for this situation.”…””}”(hjW
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÌhjS
  ubhÌ)”}”(hŒjNOTE: The method with a top-level kbuild file is recommended
but may be impractical in certain situations.”h]”hŒjNOTE: The method with a top-level kbuild file is recommended
but may be impractical in certain situations.”…””}”(hje
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÑhjS
  ubji  )”}”(hhh]”(jn  )”}”(hXK  Use a top-level kbuild file
If you have two modules, foo.ko and bar.ko, where
foo.ko needs symbols from bar.ko, you can use a
common top-level kbuild file so both modules are
compiled in the same build. Consider the following
directory layout::

        ./foo/ <= contains foo.ko
        ./bar/ <= contains bar.ko

The top-level kbuild file would then look like::

        #./Kbuild (or ./Makefile):
                obj-m := foo/ bar/

And executing::

        $ make -C $KDIR M=$PWD

will then do the expected and compile both modules with
full knowledge of symbols from either module.
”h]”(jt  )”}”(hŒUse a top-level kbuild file”h]”hŒUse a top-level kbuild file”…””}”(hjz
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´Mèhjv
  ubj„  )”}”(hhh]”(hÌ)”}”(hŒØIf you have two modules, foo.ko and bar.ko, where
foo.ko needs symbols from bar.ko, you can use a
common top-level kbuild file so both modules are
compiled in the same build. Consider the following
directory layout::”h]”hŒ×If you have two modules, foo.ko and bar.ko, where
foo.ko needs symbols from bar.ko, you can use a
common top-level kbuild file so both modules are
compiled in the same build. Consider the following
directory layout:”…””}”(hj‹
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÕhjˆ
  ubjŠ  )”}”(hŒ3./foo/ <= contains foo.ko
./bar/ <= contains bar.ko”h]”hŒ3./foo/ <= contains foo.ko
./bar/ <= contains bar.ko”…””}”hj™
  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´MÛhjˆ
  ubhÌ)”}”(hŒ0The top-level kbuild file would then look like::”h]”hŒ/The top-level kbuild file would then look like:”…””}”(hj§
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´MÞhjˆ
  ubjŠ  )”}”(hŒ5#./Kbuild (or ./Makefile):
        obj-m := foo/ bar/”h]”hŒ5#./Kbuild (or ./Makefile):
        obj-m := foo/ bar/”…””}”hjµ
  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´Màhjˆ
  ubhÌ)”}”(hŒAnd executing::”h]”hŒAnd executing:”…””}”(hjÃ
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mãhjˆ
  ubjŠ  )”}”(hŒ$ make -C $KDIR M=$PWD”h]”hŒ$ make -C $KDIR M=$PWD”…””}”hjÑ
  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´Måhjˆ
  ubhÌ)”}”(hŒewill then do the expected and compile both modules with
full knowledge of symbols from either module.”h]”hŒewill then do the expected and compile both modules with
full knowledge of symbols from either module.”…””}”(hjß
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mçhjˆ
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hjv
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´Mèhjs
  ubjn  )”}”(hX  Use "make" variable KBUILD_EXTRA_SYMBOLS
If it is impractical to add a top-level kbuild file,
you can assign a space separated list
of files to KBUILD_EXTRA_SYMBOLS in your build file.
These files will be loaded by modpost during the
initialization of its symbol tables.

”•m      h]”(jt  )”}”(hŒ(Use "make" variable KBUILD_EXTRA_SYMBOLS”h]”hŒ,Use â€œmakeâ€ variable KBUILD_EXTRA_SYMBOLS”…””}”(hjý
  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1js  h³hÊh´Mðhjù
  ubj„  )”}”(hhh]”hÌ)”}”(hŒåIf it is impractical to add a top-level kbuild file,
you can assign a space separated list
of files to KBUILD_EXTRA_SYMBOLS in your build file.
These files will be loaded by modpost during the
initialization of its symbol tables.”h]”hŒåIf it is impractical to add a top-level kbuild file,
you can assign a space separated list
of files to KBUILD_EXTRA_SYMBOLS in your build file.
These files will be loaded by modpost during the
initialization of its symbol tables.”…””}”(hj  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Mëhj  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jƒ  hjù
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jm  h³hÊh´Mðhjs
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jh  hjS
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´MÌhjB
  h²hubeh}”(h]”Œ$symbols-from-another-external-module”ah ]”h"]”Œ$symbols from another external module”ah$]”h&]”uh1hµhjá  h²hh³hÊh´MÊubeh}”(h]”Œmodule-versioning”ah ]”h"]”Œmodule versioning”ah$]”h&]”uh1hµhh·h²hh³hÊh´M…ubh¶)”}”(hhh]”(h»)”}”(hŒTips & Tricks”h]”hŒTips & Tricks”…””}”(hjG  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjD  h²hh³hÊh´Móubh¶)”}”(hhh]”(h»)”}”(hŒTesting for CONFIG_FOO_BAR”h]”hŒTesting for CONFIG_FOO_BAR”…””}”(hjX  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1hºhjU  h²hh³hÊh´Möubjv  )”}”(hXZ  Modules often need to check for certain `CONFIG_` options to
decide if a specific feature is included in the module. In
kbuild this is done by referencing the `CONFIG_` variable
directly::

        #fs/ext2/Makefile
        obj-$(CONFIG_EXT2_FS) += ext2.o

        ext2-y := balloc.o bitmap.o dir.o
        ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o”h]”(hÌ)”}”(hŒ¼Modules often need to check for certain `CONFIG_` options to
decide if a specific feature is included in the module. In
kbuild this is done by referencing the `CONFIG_` variable
directly::”h]”(hŒ(Modules often need to check for certain ”…””}”(hjj  h²hh³Nh´Nubjü  )”}”(hŒ	`CONFIG_`”h]”hŒCONFIG_”…””}”(hjr  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jû  hjj  ubhŒn options to
decide if a specific feature is included in the module. In
kbuild this is done by referencing the ”…””}”(hjj  h²hh³Nh´Nubjü  )”}”(hŒ	`CONFIG_`”h]”hŒCONFIG_”…””}”(hj„  h²hh³Nh´Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jû  hjj  ubhŒ variable
directly:”…””}”(hjj  h²hh³Nh´Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1hËh³hÊh´Møhjf  ubjŠ  )”}”(hŒ|#fs/ext2/Makefile
obj-$(CONFIG_EXT2_FS) += ext2.o

ext2-y := balloc.o bitmap.o dir.o
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o”h]”hŒ|#fs/ext2/Makefile
obj-$(CONFIG_EXT2_FS) += ext2.o

ext2-y := balloc.o bitmap.o dir.o
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o”…””}”hjœ  sbah}”(h]”h ]”h"]”h$]”h&]”j™  jš  uh1j‰  h³hÊh´Mýhjf  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ju  h³hÊh´MøhjU  h²hubeh}”(h]”Œtesting-for-config-foo-bar”ah ]”h"]”Œtesting for config_foo_bar”ah$]”h&]”uh1hµhjD  h²hh³hÊh´Möubeh}”(h]”Œtips-tricks”ah ]”h"]”Œtips & tricks”ah$]”h&]”uh1hµhh·h²hh³hÊh´Móubeh}”(h]”Œbuilding-external-modules”ah ]”h"]”Œbuilding external modules”ah$]”h&]”uh1hµhhh²hh³hÊh´Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”hÊuh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(hºNŒ	generator”NŒ	datestamp”NŒsource_link”NŒ
source_url”NŒtoc_backlinks”Œentry”Œfootnote_backlinks”KŒsectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒstrip_classes”NŒreport_level”KŒ
halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ	traceback”ˆŒinput_encoding”Œ	utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”jë  Œerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œlanguage_code”Œen”Œrecord_dependencies”NŒconfig”NŒ	id_prefix”hŒauto_id_prefix”Œid”Œdump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”hÊŒ_destination”NŒ_config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ	tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œdocinfo_xform”KŒsectsubtitle_xform”‰Œimage_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”(Œ-creating a kbuild file for an external module”]”j  aŒmodule installation”]”j¢  auŒrefids”}”Œnameids”}”(jÅ  jÂ  j&  j#  j  jŠ  j&  j#  j  j  j8  j5  j…  j‚  j4  j  j[  jX  jà  jÝ  j-  j*  jî  jë  j"  j  jo  jl  jæ  jã  jÞ  j²  j˜  j•  j×  jÔ  jA  j>  jÁ	  j¾	  j
  j
  j?
  j<
  j9  j6  j½  jº  jµ  j²  uŒ	nametypes”}”(jÅ  ‰j&  ‰j  ‰j&  ‰j  ‰j8  ‰j…  ‰j4  ‰j[  ‰jà  ‰j-  ‰jî  ‰j"  ‰jo  ‰jæ  ‰jÞ  ‰j˜  ‰j×  ‰jA  ‰jÁ	  ‰j
  ‰j?
  ‰j9  ‰j½  ‰jµ  ‰uh}”(jÂ  h·j#  hÛjŠ  j)  j#  jd  j  j)  j5  j  j‚  j;  j  j  jX  j  jÝ  j^  j*  jã  jë  j8  j  jØ  jl  j%  jã  jr  j²  jñ  j•  jN  jÔ  j›  j>  já  j¾	  j	  j
  jÄ	  j<
  j
  j6  jB
  jº  jD  j²  jU  uŒfootnote_refs”}”Œcitation_refs”}”Œautofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ	footnotes”]”Œ	citations”]”Œautofootnote_start”KŒsymbol_footnote_start”K Œ
id_counter”Œcollections”ŒCounter”“”}”…”R”Œparse_messages”]”Œtransform_messages”]”Œtransformer”NŒinclude_log”]”Œ
decoration”Nh²hub.