Re: [yocto-patches] [meta-rockchip][PATCH v2 1/2] make rockchip kernel tweaks easier to use

[Trevor Woerner <twoerner@gmail.com>]

On Thu 2025-12-11 @ 03:13:50 PM, Quentin Schulz via lists.yoctoproject.org wrote:
> Hi Trevor,
> 
> On 12/8/25 8:35 PM, Trevor Woerner via lists.yoctoproject.org wrote:
> > If the machines defined in this layer are used, they will want to pull
> > in the kmeta data that is also provided in this layer when configuring
> > the Linux kernel. This all works automatically if linux-yocto or
> > linux-yocto-dev are used. But it causes build failures if a kernel
> > recipe is used or defined that is not one of these two.
> > 
> 
> The issue is that we have machine configuration files settting the
> KERNEL_FEATURES variable in a conf file instead of having it in the kernel
> recipe.

As far as I am aware, there is no rule saying that KERNEL_FEATURES can
only appear in kernel recipes; in fact I think that's the wrong way to
think about them. The kernel provides many things, and each of these
things can be configured in the kernel.

For example the kernel provides filesystem types. If you developed
an application that, say, provided a fancy dashboard or status or
configuration or debug interface to a particular filesystem, then
I strongly feel the relevant KERNEL_FEATURES additions should be
contained in the Yocto Project recipe for that application. Perhaps
your application needs the CONFIG_*_FS_DEBUG flag enabled in the kernel
in order to work correctly or fully, in that case the KERNEL_FEATURES
should be specified in the recipe. There's no point having a user
include your app in their image if the kernel doesn't provide the
interface or data it needs to work correctly. I would even go a step
further than that: ideally all Yocto Project recipes would include the
KERNEL_FEATURES on which they depend, regardless of whether or not that
feature is present by default via, say, the in-kernel defconfig. For
example, a user might not be relying on some defconfig (regardless from
where it comes, whether it be in-kernel or from a BSP). In that case,
the recipe should work "out-of-the-box" for a user who is including
it in their image. My guess is that currently throughout oe-core and
meta-oe there are probably some recipes that have an implicit dependency
on some kernel feature being enabled; I think those should be make
explicit via KERNEL_FEATURES.

Another thing a kernel provides is architecture- and SoC-specific
code. In the same way as my user-space application example above,
architecture- and SoC-specific KERNEL_FEATURES should be specified in
machine configurations, not kernel recipes. Somebody building an image
for a Rockchip-based device does not need (for example) Qualcomm support
(and associated Qualcomm-specific drivers and features) in their kernel.
In meta-rockchip, using one of the meta-rockchip-defined MACHINES
disables Qualcomm (and others) support. This saves you in image size,
it saves you in runtime RAM usage, and it shrinks the attack surface
somewhat. You're suggesting meta-rockchip should have bbappends for
various known kernel recipes in order to provide the user with the same
kernel configuration adjustments, but this doesn't help a Rockchip user
if/when they define their own kernel recipe, or use, say, linux-stable
or linux-mainline from some of the kernel-specific Yocto Project layers
that exist. In that case they will get no error or warnings, they just
won't have any Rockchip-specific KERNEL_FEATURES enabled.

In an ideal world kernels would be configured starting with nothing,
from the ground up, by using KERNEL_FEATURES. BSP layers would add
KERNEL_FEATURES based on which SoC/board you are using which would come
into your build depending on which MACHINE you chose, software layers
would add KERNEL_FEATURES based on what software you're including. A
basic set of KERNEL_FEATURES would be available that most people would
want, but it could be overridden or tweaked as the user sees fit for
their purposes.

I feel the correct location for Rockchip-specific KERNEL_FEATURES is in
Rockchip MACHINE definitions, and I discovered they can be cumbersome to
use when they are only available for specific kernel recipes. Moving the
core of these files into an *.inc makes them available for all kernel
recipes.

> kernel-yocto.bbclass is the one reading the variable and expecting to find
> an associated file defining what to do based on that variable.
> 
> So, by setting KERNEL_FEATURES in the machine conf file but only adding the
> necessary files to linux-yocto and linux-yocto-dev, any other recipe which
> inherits kernel-yocto.bbclass will fail to find the file associated with
> KERNEL_FEATURES (as the former is missing, currently only added in local
> bbappens and the latter is set from a conf file so always set essentially).
> 
> > Putting this layer-specific metadata into an *.inc file (then
> > referencing it in the kernel bbappends provided in this layer) makes
> > that metadata available to any other kernel recipe through the "require"
> > or "include" mechanism. Any other kernel recipe that is created can pull
> > in this metadata using either of these lines in the kernel recipe:
> > 
> > 	require recipes-kernel/linux/linux-rockchip.inc
> > 	include recipes-kernel/linux/linux-rockchip.inc
> > 
> 
> That's an okay work-around but why not move KERNEL_FEATURES into the
> recipe/bbappend so we don't break by default recipes which inherits
> kernel-yocto? You can still have this into a .inc file so it's easier to
> include for other kernel-yocto-inheriting recipes.
> 
> See meta-arm, oe-core with linux-yocto. I don't understand why we have
> KERNEL_FEATURES:append:pn-linux-yocto and
> KERNEL_FEATURES:append:pn-linux-yocto-rt in
> meta/conf/machine/include/qemu.inc though. I'm assuming we can move that to
> linux-yocto and linux-yocto-rt recipes.
> 
> Cheers,
> Quentin
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#2765): https://lists.yoctoproject.org/g/yocto-patches/message/2765
> Mute This Topic: https://lists.yoctoproject.org/mt/116682100/900817
> Group Owner: yocto-patches+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/yocto-patches/leave/13168745/900817/63955952/xyzzy [twoerner@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
> 
>