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<var>=<value> 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 <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <sst@poczta.fm>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <richard.purdie@linuxfoundation.org>
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 <F.Kloeckner@weinmann-emt.de>
(From OE-Core rev: aab4517b4649917abd519ea85a20fd9d51bf3d99)
Signed-off-by: Enrico Jörns <ejo@pengutronix.de>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <christian.taedcke@weidmueller.com>
Signed-off-by: Mathieu Dubois-Briand <mathieu.dubois-briand@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
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 <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
[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 <paul@pbarker.dev>
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Right before this message is printed, the in-tree defconfig is checked
against the one in WORKDIR. If it is different, and therefore either
provided through SRC_URI or patched, then the message is printed.
Therefore, the debug message is incorrect and should say that a patched
defconfig was detected and overwritten.
Fixes: 004da4c6c602 ("kernel-yocto: split meta data gathering into patch and config phases")
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
(From OE-Core rev: f25717bff291ca225a70e63d3266656d8e643531)
Signed-off-by: Quentin Schulz <quentin.schulz@cherry.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The kernel has special handling of ${S} and it is therefore expected to be empty
at do_unpack time. For now, ignore this QA check until the kernel unpack process
can be more standardised.
(From OE-Core rev: f2f3f965d6d5fc19b357891e8c55473782124662)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The only real reason for oe-local-files was to support S = WORKDIR. With changes to
drop support for that, it makes sense to simplify devtool and to try and make both
the code and the processes/workflows simpler.
This patch drops support for S = WORKDIR, removes oe-local-files and then updates
the test cases to match this new situation.
At the code level, we assume we can always now track code changes using git and
that things committed into git are handled as patches (as before) but delta against
HEAD is saved as specific file level changes to the recipe.
One test is disabled as it is no longer approproate. It is being keped until we can
make WORKDIR != UNPACKDIR at which point it should be revisited.
(From OE-Core rev: ce8190c519052fed10b5233697b69a75868db45a)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Replace references of WORKDIR with UNPACKDIR where it makes sense to do
so in preparation for changing the default value of UNPACKDIR.
(From OE-Core rev: 1f18b9a512800860d5153d89eb82b56388efad6f)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Work through the initial issues I found where we need to change WORKDIR
to UNPACKDIR.
(From OE-Core rev: 86fec41b1e809d1a2fa2feadc26d29020df53d39)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The ability to patch the kernel-yocto metadata was added to support
debug and easier test cycles on kernel-cache provided fragments. As
such, it was very simple and has limited functionality.
That being said, it is an available feature and can be improved to
handle patches that fail to apply.
The main kernel patching is already handled by the kern-tools, so
we extend the patching of the meta-data to same tools and inherit
more functinality from the scripts.
[YOCTO #15266]
(From OE-Core rev: e867addd6c2f508f7a95e72222e750d37f3d19d8)
Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
The hooks are pulled from the impure environment and are often broken in
our environments. There is no reason to add extra metadata or verify the
commit message as its arbitrary to turn the tarball into a git repo.
(From OE-Core rev: dd52102a6c3f69d156bfcf85827123c96f18d5a1)
Signed-off-by: William A. Kennington III <wak@google.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
strip can be coming from binutils or from llvm
in some cases llvm-strip can fail on kernel
Subprocess output:aarch64-yoe-linux-llvm-strip: error: Link field value 28 in section .rela.dyn is not a symbol table
This helps in selecting which strip is used when building kernel
(From OE-Core rev: 03973c8c1c93ddb1c8e05b773bfcc45aed73a99f)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
This helps in switching toolchains cleanly for kernel build
between gcc and clang
Currently, some kernels allow building with clang but not all
the distro might use clang as default system compiler but kernel
may demand gcc which is provided via KERNEL_* variables, however
kernel does use OBJCOPY at places during build and it maybe set
to use llvm objcopy when using clang. That should be a deliberate
setting when clang is used for kernel as well, otherwise it should
use binutils provided objcopy
(From OE-Core rev: 17b409f2fd97894e0943d13c2cb0d52abde647e3)
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Cc: Bruce Ashfield <bruce.ashfield@gmail.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Improve the fatal error message of the yocto-kernel-tools symbol_why.py
and shows the command that generate the error as it can help understand
the root cause of the error.
(From OE-Core rev: 54ae08779071f2e97bff0ff6514ede3124312c3b)
Signed-off-by: Jose Quaresma <jose.quaresma@foundries.io>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Move classes to classes-global or classes-recipe as appropriate to take
advantage of new bitbake functionality to check class scope/usage.
(From OE-Core rev: f5c128008365e141082c129417eb72d2751e8045)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
