Understand "kernel headers" , "out of tree modules" , "build external kernel modules"

[bsp_dev]

Hi,
I have several questions regarding the L4T 34.1.1 developer guide - “Preparing to Build External Kernel Modules” section and kernel build in general:

1. Can you explain (or refer to a good learning source) the following terms and why/when I’m gonna need them:
   1.1. kernel headers
   1.2. kernel source tree
   1.3. out of tree kernel module
   1.4. build out-of-tree modules that are compatible with a Linux kernel source tree without building the entire kernel image.

2. Upon finishing all the steps in “Building the Kernel” should i perform the steps in
   “To build external kernel modules” or to skip it straight to flashing the board?

The steps are:
"

1. If you are cross-compiling the kernel, ensure that the CROSS_COMPILE environment variable is set as described in preceding sections.
2. Enter these commands to build an out-of-tree kernel module:
   $ cd <path_to_module_source>
   $ make ARCH=arm64 –C <kernel_directory> M=$(pwd)
3. Enter these commands to strip unneeded symbols from the kernel module:
   $ <tool_chain_path>/aarch64-linux-gnu-strip -–strip-unneeded <path-of-kernel-module.ko>

Thanks

[linuxdev]

The C programming language tends to require knowledge of both the “function signature” (a declaration of how a function is to be called), and also of the implementation of the function (the actual function). One implementation must exist, and then anything using that implementation must know how to call the function. Header files contain the “signatures” (function declarations) and any caller of the function tends to include the header file (the actual function source is not needed to call a function).

The kernel source tree contains both headers and implementations.

One can also obtain just the headers of the kernel source tree. Only useful if you are compiling third party code which needs to know how to call functions, and is not shipped with the kernel source. Most drivers and code are “in tree”, and not “out of tree”. Sometimes someone will provide a driver in source code form which does not ship with the kernel, meaning it is “out of tree”. To build out of tree content you could use just headers (after configuration) or the full source (which contains the headers as well). The trick with external out of tree module build is you must tell the compiler where to find the headers, whereas if it is in the full source, then the compiler knows where headers are.

Unless you have source code for a kernel module which does not ship with the kernel, e.g., something downloaded separately from a manufacturer which is not already in the main source code, you can ignore out of tree module build. You’d still build modules, but not the external ones since you would not normally have any.

The “<path_to_module_source>” is just where the source code lives at or is unpacked at. Typically it will be a subdirectory of “/usr/src” on a running system, but since you are cross compiling, it will be somewhere else. An example of “somewhere else” might be (this can vary):
~/nvidia/nvidia_sdk/JetPack_...version.../Linux_for_Tegra/sources/kernel/kernel-4.9
(it just depends on where you or JetPack unpacked the source code and expanded it to files and directories)

If you are learning to build external modules I suggest you first try building a kernel and the modules within the source tree. When you succeed with this I’d move on to the case of building out of tree (external).

[bsp_dev]

Thank you!