The kernel Metadata consists of three primary types of files:
scc
[1]
description files, configuration fragments, and patches.
The scc
files define variables and include or
otherwise reference any of the three file types.
The description files are used to aggregate all types of kernel
Metadata into
what ultimately describes the sources and the configuration required
to build a Linux kernel tailored to a specific machine.
The scc
description files are used to define two
fundamental types of kernel Metadata:
Features
Board Support Packages (BSPs)
Features aggregate sources in the form of patches and configuration fragments into a modular reusable unit. You can use features to implement conceptually separate kernel Metadata descriptions such as pure configuration fragments, simple patches, complex features, and kernel types. Kernel types define general kernel features and policy to be reused in the BSPs.
BSPs define hardware-specific features and aggregate them with kernel types to form the final description of what will be assembled and built.
While the kernel Metadata syntax does not enforce any logical separation of configuration fragments, patches, features or kernel types, best practices dictate a logical separation of these types of Metadata. The following Metadata file hierarchy is recommended:
base
/
bsp/
cfg/
features/
ktypes/
patches/
The bsp
directory contains the
BSP descriptions.
The remaining directories all contain "features".
Separating bsp
from the rest of the structure
aids conceptualizing intended usage.
Use these guidelines to help place your scc
description files within the structure:
If your file contains
only configuration fragments, place the file in the
cfg
directory.
If your file contains
only source-code fixes, place the file in the
patches
directory.
If your file encapsulates
a major feature, often combining sources and configurations,
place the file in features
directory.
If your file aggregates
non-hardware configuration and patches in order to define a
base kernel policy or major kernel type to be reused across
multiple BSPs, place the file in ktypes
directory.
These distinctions can easily become blurred - especially as
out-of-tree features slowly merge upstream over time.
Also, remember that how the description files are placed is
a purely logical organization and has no impact on the functionality
of the kernel Metadata.
There is no impact because all of cfg
,
features
, patches
, and
ktypes
, contain "features" as far as the kernel
tools are concerned.
Paths used in kernel Metadata files are relative to
base
, which is either
FILESEXTRAPATHS
if you are creating Metadata in
recipe-space,
or the top level of
yocto-kernel-cache
if you are creating
Metadata outside of the recipe-space.
[1]
scc
stands for Series Configuration
Control, but the naming has less significance in the
current implementation of the tooling than it had in the
past.
Consider scc
files to be description files.