€•      Œ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Œ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hð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”uh1hî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j4  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jB  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jS  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjP  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jg  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K.hjc  ubhŒliteral_block”“”)”}”(hŒ%$ make -C <path_to_kernel_dir> M=$PWD”h]”hŒ%$ make -C <path_to_kernel_dir> M=$PWD”…””}”hjw  sbah}”(h]”h ]”h"]”h$]”h&]”Œ	xml:space”Œpreserve”uh1ju  hŸh¶h K0hjc  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jc  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jc  ubjv  )”}”(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†  uh1ju  hŸh¶h K7hjc  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jc  ubjv  )”}”(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†  uh1ju  hŸh¶h K<hjc  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jc  ubjb  )”}”(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&]”uh1ja  hŸh¶h KBhjc  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  hŸh¶h K.hjP  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 KEubjb  )”}”(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j8  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jF  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ja  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j_  hŸh¶h KThj[  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jt  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KQhjq  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jo  hj[  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h KThjV  ubjZ  )”}”(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]”(j`  )”}”(hŒM=$PWD”h]”hŒM=$PWD”…””}”(hj’  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j_  hŸh¶h KZhjŽ  ubjp  )”}”(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&]”uh1jo  hjŽ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h KZhjV  ubjZ  )”}”(hŒMMO=$BUILD_DIR
Specifies a separate output directory for the external module.
”h]”(j`  )”}”(hŒMO=$BUILD_DIR”h]”hŒMO=$BUILD_DIR”…””}”(hjÁ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j_  hŸh¶h K]hj½  ubjp  )”}”(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&]”uh1jo  hj½  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h K]hjV  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jT  hj&  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  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`ubjb  )”}”(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j#  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j1  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kghj  ubjU  )”}”(hhh]”(jZ  )”}”(hŒ…modules
The default target for external modules. It has the
same functionality as if no target was specified. See
description above.
”h]”(j`  )”}”(hŒmodules”h]”hŒmodules”…””}”(hjF  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j_  hŸh¶h KqhjB  ubjp  )”}”(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jW  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KohjT  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jo  hjB  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h Kqhj?  ubjZ  )”}”(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]”(j`  )”}”(hŒmodules_install”h]”hŒmodules_install”…””}”(hju  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j_  hŸh¶h Kwhjq  ubjp  )”}”(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 Nubhï)”}”(hŒ`Module Installation`_”h]”hŒModule Installation”…””}”(hjŽ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œname”ŒModule Installation”j   Œmodule-installation”uh1hî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&]”uh1jo  hjq  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h Kwhj?  ubjZ  )”}”(hŒ?clean
Remove all generated files in the module directory only.
”h]”(j`  )”}”(hŒclean”h]”hŒclean”…””}”(hj¹  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j_  hŸh¶h Kzhjµ  ubjp  )”}”(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&]”uh1jo  hjµ  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h Kzhj?  ubjZ  )”}”(hŒ6help
List the available targets for external modules.
”h]”(j`  )”}”(hŒhelp”h]”hŒhelp”…””}”(hjè  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j_  hŸh¶h K}hjä  ubjp  )”}”(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&]”uh1jo  hjä  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h K}hj?  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jT  hj  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  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€ubjb  )”}”(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j<  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K‚hj8  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jJ  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K†hj8  ubjv  )”}”(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jX  sbah}”(h]”h ]”h"]”h$]”h&]”j…  j†  uh1ju  hŸh¶h Kˆhj8  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  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žhubjv  )”}”(hŒobj-m := <module_name>.o”h]”hŒobj-m := <module_name>.o”…””}”hj›  sbah}”(h]”h ]”h"]”h$]”h&]”j…  j†  uh1ju  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žhubjv  )”}”(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†  uh1ju  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žhubjv  )”}”(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†  uh1ju  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¬ubjb  )”}”(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   ubjv  )”}”(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j   sbah}”(h]”h ]”h"]”h$]”h&]”j…  j†  uh1ju  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j.  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÆhj   ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  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jM  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjJ  hžhhŸh¶h KÏubjb  )”}”(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j_  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÑhj[  ubh¸)”}”(hŒExample 2::”h]”hŒ
Example 2:”…””}”(hjm  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÕhj[  ubjv  )”}”(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†  uh1ju  hŸh¶h K×hj[  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j[  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j[  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j[  ubjv  )”}”(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†  uh1ju  hŸh¶h Këhj[  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  hŸh¶h KÑhjJ  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öubjb  )”}”(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à  ubjv  )”}”(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†  uh1ju  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&]”uh1ja  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j$  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j5  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhj$  hžhubjb  )”}”(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jR  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M	hjN  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jL  hjI  ubjM  )”}”(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jj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Mhjf  ubjU  )”}”(hhh]”jZ  )”}”(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]”(j`  )”}”(hŒNOTE:”h]”hŒNOTE:”…””}”(hj  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j_  hŸh¶h Mhj{  ubjp  )”}”(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&]”uh1jo  hj{  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h Mhjx  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jT  hjf  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jL  hjI  ubeh}”(h]”h ]”h"]”h$]”h&]”Œbullet”Œ*”uh1jG  hŸh¶h M	hjC  ubah}”(h]”h ]”h"]”h$]”h&]”uh1ja  hŸh¶h M	hj$  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ubjb  )”}”(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Õ  ubjv  )”}”(hŒ#include <linux/module.h>”h]”hŒ#include <linux/module.h>”…””}”hjç  sbah}”(h]”h ]”h"]”h$]”h&]”j…  j†  uh1ju  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&]”uh1ja  hŸh¶h MhjÄ  hžhubeh}”(h]”Œkernel-includes”ah ]”h"]”Œkernel includes”ah$]”h&]”uh1h¡hj$  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"ubjb  )”}”(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j"  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j4  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M)hj"  ubjv  )”}”(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jB  sbah}”(h]”h ]”h"]”h$]”h&]”j…  j†  uh1ju  hŸh¶h M-hj"  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  hŸh¶h M$hj  hžhubeh}”(h]”Œsingle-subdirectory”ah ]”h"]”Œsingle subdirectory”ah$]”h&]”uh1h¡hj$  hžhhŸh¶h M"ubh¢)”}”(hhh]”(h§)”}”(hŒSeveral Subdirectories”h]”hŒSeveral Subdirectories”…””}”(hja  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj^  hžhhŸh¶h M4ubjb  )”}”(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js  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M6hjo  ubjv  )”}”(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†  uh1ju  hŸh¶h M9hjo  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jo  ubjv  )”}”(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†  uh1ju  hŸh¶h MFhjo  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jo  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jo  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  hŸh¶h M6hj^  hžhubeh}”(h]”Œseveral-subdirectories”ah ]”h"]”Œseveral subdirectories”ah$]”h&]”uh1h¡hj$  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žhubjb  )”}”(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&]”uh1ja  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žhubjb  )”}”(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j"  ubah}”(h]”h ]”h"]”h$]”h&]”uh1ja  hŸh¶h MehjÝ  hžhubh¢)”}”(hhh]”(h§)”}”(hŒINSTALL_MOD_PATH”h]”hŒINSTALL_MOD_PATH”…””}”(hj=  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj:  hžhhŸh¶h Mhubjb  )”}”(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jO  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MjhjK  ubjv  )”}”(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j]  sbah}”(h]”h ]”h"]”h$]”h&]”j…  j†  uh1ju  hŸh¶h MnhjK  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jk  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MqhjK  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  hŸh¶h Mjhj:  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 Mwubjb  )”}”(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˜  ubjv  )”}”(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†  uh1ju  hŸh¶h Mhj˜  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  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\j#  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’ubjb  )”}”(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j	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M™hj	  ubjv  )”}”(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†  uh1ju  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j9	  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jG	  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jU	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M¥hj	  ubhŒenumerated_list”“”)”}”(hhh]”(jM  )”}”(hŒ;It lists all exported symbols from vmlinux and all modules.”h]”h¸)”}”(hjj	  h]”hŒ;It lists all exported symbols from vmlinux and all modules.”…””}”(hjl	  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M§hjh	  ubah}”(h]”h ]”h"]”h$]”h&]”uh1jL  hje	  ubjM  )”}”(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&]”uh1jL  hje	  ubeh}”(h]”h ]”h"]”h$]”h&]”Œenumtype”Œarabic”Œprefix”hŒsuffix”Œ)”uh1jc	  hj	  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  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«ubjb  )”}”(hX  Exported symbols have information stored in __ksymtab or __ksymtab_gpl
sections. Symbol names and namespaces are stored in __ksymtab_strings,
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 or __kcrctab_gpl.

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XD  Exported symbols have information stored in __ksymtab or __ksymtab_gpl
sections. Symbol names and namespaces are stored in __ksymtab_strings,
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 or __kcrctab_gpl.”h]”hXD  Exported symbols have information stored in __ksymtab or __ksymtab_gpl
sections. Symbol names and namespaces are stored in __ksymtab_strings,
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 or __kcrctab_gpl.”…””}”(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&]”uh1ja  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¿ubjb  )”}”(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&]”uh1ja  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j1
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj.
  hžhhŸh¶h MÉubjb  )”}”(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jC
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MËhj?
  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jQ
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÐhj?
  ubjU  )”}”(hhh]”(jZ  )”}”(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]”(j`  )”}”(hŒUse a top-level kbuild file”h]”hŒUse a top-level kbuild file”…””}”(hjf
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1j_  hŸh¶h Mçhjb
  ubjp  )”}”(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jw
  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h MÔhjt
  ubjv  )”}”(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†  uh1ju  hŸh¶h MÚhjt
  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jt
  ubjv  )”}”(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†  uh1ju  hŸh¶h Mßhjt
  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jt
  ubjv  )”}”(hŒ$ make -C $KDIR M=$PWD”h]”hŒ$ make -C $KDIR M=$PWD”…””}”hj½
  sbah}”(h]”h ]”h"]”h$]”h&]”j…  j†  uh1ju  hŸh¶h Mähjt
  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jt
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jo  hjb
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h Mçhj_
  ubjZ  )”}”(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.

”h]”(j`  )”}”(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&]”uh1j_  hŸh¶h Mïhjå
  ubjp  )”}”(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&]”uh1jo  hjå
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jY  hŸh¶h Mïhj_
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jT  hj?
  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  hŸh¶h MËhj.
  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j3  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hj0  hžhhŸh¶h Mòubh¢)”}”(hhh]”(h§)”}”(hŒTesting for CONFIG_FOO_BAR”h]”hŒTesting for CONFIG_FOO_BAR”…””}”(hjD  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hjA  hžhhŸh¶h Mõubjb  )”}”(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jV  hžhhŸNh Nubjè  )”}”(hŒ	`CONFIG_`”h]”hŒCONFIG_”…””}”(hj^  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jç  hjV  ubhŒn options to
decide if a specific feature is included in the module. In
kbuild this is done by referencing the ”…””}”(hjV  hžhhŸNh Nubjè  )”}”(hŒ	`CONFIG_`”h]”hŒCONFIG_”…””}”(hjp  hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jç  hjV  ubhŒ variable
directly:”…””}”(hjV  hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M÷hjR  ubjv  )”}”(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†  uh1ju  hŸh¶h MühjR  ubeh}”(h]”h ]”h"]”h$]”h&]”uh1ja  hŸh¶h M÷hjA  hžhubeh}”(h]”Œtesting-for-config-foo-bar”ah ]”h"]”Œtesting for config_foo_bar”ah$]”h&]”uh1h¡hj0  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”]”hðaŒmodule installation”]”jŽ  auŒrefids”}”Œnameids”}”(j±  j®  j  j  jy  jv  j  j  jý  jú  j$  j!  jq  jn  j   j  jG  jD  jÌ  jÉ  j  j  jÚ  j×  j  j  j[  jX  jÒ  jÏ  jÊ  jž  j„  j  jÃ  jÀ  j-  j*  j­	  jª	  jú	  j÷	  j+
  j(
  j%  j"  j©  j¦  j¡  jž  uŒ	nametypes”}”(j±  ‰j  ‰jy  ‰j  ‰jý  ‰j$  ‰jq  ‰j   ‰jG  ‰jÌ  ‰j  ‰jÚ  ‰j  ‰j[  ‰jÒ  ‰jÊ  ‰j„  ‰jÃ  ‰j-  ‰j­	  ‰jú	  ‰j+
  ‰j%  ‰j©  ‰j¡  ‰uh}”(j®  h£j  hÇjv  j  j  jP  jú  j  j!  j   jn  j'  j  j|  jD  jï  jÉ  jJ  j  jÏ  j×  j$  j  jÄ  jX  j  jÏ  j^  jž  jÝ  j  j:  jÀ  j‡  j*  jÍ  jª	  jú  j÷	  j°	  j(
  jý	  j"  j.
  j¦  j0  jž  jA  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.