linux/poky.git/meta/classes-recipe/kernel-yocto.bbclass, branch master

The poky repository master branch is no longer being updated.

2025-11-07T13:31:53+00:00

You can either: a) switch to individual clones of bitbake, openembedded-core, meta-yocto and yocto-docs b) use the new bitbake-setup You can find information about either approach in our documentation: https://docs.yoctoproject.org/ Note that "poky" the distro setting is still available in meta-yocto as before and we continue to use and maintain that. Long live Poky! Some further information on the background of this change can be found in: https://lists.openembedded.org/g/openembedded-architecture/message/2179 Signed-off-by: Richard Purdie

meta: remove S in recipes that fetch from git via setting BB_GIT_DEFAULT_DESTSUFFIX

2025-06-20T11:07:26+00:00

Removing all the S = ${WORKDIR}/git assignments works because BB_GIT_DEFAULT_DESTSUFFIX is set to match S from bitbake.conf (which itself is set to match typical tarball releases). A few recipes are setting S to a sub-directory of the git tree and need to be adjusted accordingly. bzip2 recipe is fetching a tarball and separately cloning tests; adjust the recipe to put the latter into 'bzip2-tests', instead of 'git'. devupstream.bbclass no longer needs to rewrite S, and is adjusted accordingly. Adjust scripts/lib/recipetool/append.py to not hardcode 'git' as unpack destination. Adjust kernel-yocto.bbclass to use the git unpack variable instead of hardcoding 'git' (there's also removal of repetition of string constants and a correction of workdir/unpackdir mismatch in one of the if-else branches). Ensure build-appliance-image recipe does not use 'git' as checkout directory for poky repo, but rather explicitly name it 'poky'. Ensure reproducible.py code that looks for git repositories does not hardcode 'git' but uses the destination set by BB_GIT_DEFAULT_DESTSUFFIX. Ensure recipetool does not write out unneeded S settings into newly created recipes that fetch from git. Adjust selftest to not hardcode 'git' as unpack directory. (From OE-Core rev: f80c07019ddadaf9c5fb890faabfda7920ecd15e) Signed-off-by: Alexander Kanavin Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

kernel-yocto: allow annotated options to be modified

2025-05-08T22:16:54+00:00

Bumping the kern-tools SRCREV to pickup the following commits: tools: allow fixups to conditionally change options Sometimes we have options that should either be =y or =m depending on the use case. Rather than force the options into multiple parallel and very similar fragments (which is error prone and labour intensive), we can allow an annotation in the configuration fragment that allows the default value to be overriden by a variable. The variable in question comes from a -D= on the scc or spp command line. If the define evaluates to a non-zero value a fixup is created that will modify the value when scc finishes gathering meta-data. An example of a notation would be: CONFIG_INET_TUNNEL=y # OVERRIDE:$MODULE_OR_Y CONFIG_INET_TUNNEL will be =y when standard tools (like merge-config) are used. But when scc/spp see this notation, they check the value of the variable MODULE_OR_Y, if that variable evalutes to a non-zero value, a fixup is created that will change CONFIG_INET_TUNNEL to that value before the kernel is configured. To use the annotations, scc needs to be passed a value that is used in the override expression. This has always been possible with defines (-Dx=y), so we leverage that to control these conditional overrides. In kernel-yocto, we now have a variable: KMETA_CONFIG_FEATURES KMETA_CONFIG_FEATURES ?= "" Which defaults to empty, the only feature that is currently implemented is "prefer-modules". When prefer-modules is detected in the kmeta config features, the following define is passed to scc: -DMODULE_OR_Y=m Which as you can see from the above INET_TUNNEL example, will evaluate to "m" and will override the default of "y". (From OE-Core rev: 4eb24e85e815cee0e310e98ce4384d4cdeeba69f) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel-yocto: move the cp of ${KBUILD_DEFCONFIG} file outside if body

2025-01-27T15:47:11+00:00

In both true/false cases, we will cp the file, so move the invocation after the if body. In addition, misleading comment has been removed. (From OE-Core rev: fdd7fec29314b3cd07a98943bbbf6996877e90f4) Signed-off-by: Slawomir Stepien Signed-off-by: Richard Purdie

classes/recipes: Switch virtual/XXX-gcc to virtual/cross-cc (and c++/binutils)

2025-01-21T23:09:33+00:00

The idea of the base class dependency is to say "yes, I need a C cross compiler" and this was never meant to be gcc specific. Looking at the codebase, whilst we code triplets into this, it does overcomplicate things as there are only ever limited, "target", "sdk" and the class extended versions like mutlilib. After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc. This lets us remove the "gcc" specific element as well as removing the over complicated triplet usage. At the same time, change the much less widely used "g++" variant to "c++" for similar reasons and remove the triplet from virtual/XXX-binutils too. Backwards compatibility mappings could be left but are just going to confuse things in future so we'll just require users to update. This simplification, whilst disruptive for any toolchain focused layers, will make improved toolchain selection in the future much easier. Since we no longer have overlapping variables, some code for that can just be removed. The class extension code does need to start remapping some variables but not the crosssdk target recipe names. This patch is in two pieces, this one handles the renaming with the functional changes separate in a second for easier review even if this breaks bisection. (From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0) Signed-off-by: Richard Purdie

kernel-yocto: make kernel commits reproducible

2025-01-21T13:26:07+00:00

The git commit hashes for the kernel checkout are not reproducible under certain conditions: - If the git repository is initialized on an archive (rather than a git), the initial git commit not only has the current user name set, it also uses the current system time as committer and author date. This will affect the initial git hash and thus all subsequent ones. - The patches applied by the kern-tools have a valid author and date. However, their committer again depends on the user building the BSP. This is an issue, for example, if one compiles a kernel with CONFIG_LOCALVERSION_AUTO enabled where the commit hash lands into the kernel and thus the package version. This not only makes the package version non-reproducible, but also leads to version mismatches between kernel modules built against a fresh kernel checkout and the kernel retrieved from the sstate cache. The class uses 'check_git_config' from utils.bbclass, but this only sets the git user and only if none existed before. Thus it doesn't really help here. Since in Git the committer information can be set only from the environment variables GIT_COMMITTER_NAME, GIT_COMMITTER_EMAIL, and GIT_COMMITTER_DATE, we introduce a helper function to set those and apply the author settings in the same way. As values simply use PATCH_GIT_USER_NAME, PATCH_GIT_USER_EMAIL (from patch.bbclass) and SOURCE_DATE_EPOCH. For convenience, put the new helper 'reproducible_git_committer_author' into utils.bbclass next to 'check_git_config' so others can use it, too. Using this helper in kernel-yocto.bbclass makes the committer and author date/name/email for the initial commit reproducible, as well as the committer name/email for the patches applied with kern-tools. For debugging purpose, allow disabling the reproducibility features by setting KERNEL_DEBUG_TIMESTAMPS to "1". Suggested-by: Felix Klöckner (From OE-Core rev: aab4517b4649917abd519ea85a20fd9d51bf3d99) Signed-off-by: Enrico Jörns Signed-off-by: Richard Purdie

kernel-yocto: enable fetching kernel metadata using file fetcher

2024-12-23T11:41:38+00:00

If no destsuffix parameter is supplied and the file fetcher is used, the folder name (i.e. basepath) is added to the kernel-meta search directories. (From OE-Core rev: e46cc8159136ce96489e10f126405781abfbd52e) Signed-off-by: Christian Taedcke Signed-off-by: Mathieu Dubois-Briand Signed-off-by: Richard Purdie

kernel-yocto: allow early exit to configuration audit

2024-11-07T13:31:26+00:00

With the ability to tag raw configuration fragments as "hardware", there is a chance that badly behaved fragments throw warnings or cause other issues that are not applicable during development (or you understand the risk). Allow kernel configuration audit to be skipped if KMETA_AUDIT is not set (by default it is), to provide a flag for control over auditing. (From OE-Core rev: a39a1f7cf78ad1ca07438bce634a47e970f25047) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel-yocto: allow cfg fragments to be specified as required

2024-11-07T13:31:26+00:00

When .scc files are used, a configuration fragment can be declared as "hardware" (required) or "non-hardware" (optional). By default the configuration audit only warns about hardware options. We can extend that default level of auditing to configuration fragments that are on the SRC_URI or in KERNEL_FEATURES by adding the ability to put a specifier after the fragment. i.e. KERNEL_FEATURES:append = 'hardening.config:required' This is particular useful for fragments that are outside of the kernel-cache (in a layer, in a kernel tree, etc) (From OE-Core rev: 0a84a3dd00543adffdef4fcf5381faab2984541e) Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie

kernel-yocto: Support in-tree config fragments

2024-11-07T13:31:26+00:00

[This is currently an RFC as it depends on a separate patch to add support for config fragments with .config file extensions in yocto-kernel-tools: https://lists.yoctoproject.org/g/linux-yocto/message/14431] In Linux 6.8, the in-tree rv32_defconfig file for 32-bit RISC-V support was dropped in favour of a Makefile target which combines the RISC-V defconfig with a config fragment '32-bit.config'. So to build for 32-bit RISC-V using the in-tree configuration from an upstream kernel, we need to be able to enable this 32-bit config fragment. We can support this via KERNEL_FEATURES if we add the in-tree arch config directory (arch/${ARCH}/configs) to the search path. While we're here, let's also add the generic config directory (kernel/configs) to the search path so in-tree config fragments such as 'hardening.config' can be used. (From OE-Core rev: e4e50a9a93d606ba5fef8f10f1ec20deaed7ab9c) Signed-off-by: Paul Barker Signed-off-by: Bruce Ashfield Signed-off-by: Richard Purdie