On Thu, Sep 29, 2022 at 11:23 PM Jon Mason <jdma...@kudzu.us> wrote:
>
> Most machine features have corresponding kernel config fragments, but
> only a few have an entry in the kernel recipe to be automatically added.
> Adding the majority of them here.
>
> Signed-off-by: Jon Mason <jdma...@kudzu.us>
> ---
> meta/recipes-kernel/linux/linux-yocto.inc | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto.inc
> b/meta/recipes-kernel/linux/linux-yocto.inc
> index 7ea661e138d9..23ae0b4260c2 100644
> --- a/meta/recipes-kernel/linux/linux-yocto.inc
> +++ b/meta/recipes-kernel/linux/linux-yocto.inc
> @@ -33,7 +33,12 @@ KERNEL_LD:append:arc = " ${TOOLCHAIN_OPTIONS}"
>
> KERNEL_FEATURES:append:qemuall=" features/debug/printk.scc"
>
> +KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES',
> 'bluetooth', 'features/bluetooth/bluetooth.scc', '', d)}"
> +KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'efi',
> 'cfg/efi.scc', '', d)}"
> +KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'ext2',
> 'cfg/fs/ext2.scc', '', d)}"
> KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'numa',
> 'features/numa/numa.scc', '', d)}"
> +KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'pci',
> 'features/pci/pci.scc', '', d)}"
> +KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'rtc',
> 'cfg/timer/rtc.scc', '', d)}"
> KERNEL_FEATURES:append = " ${@bb.utils.contains('MACHINE_FEATURES', 'vfat',
> 'cfg/fs/vfat.scc', '', d)}"
The concept of this is ok, but there are some non-obvious details that
need to be considered.
There's a really old enhancement in bugzilla about doing a better job
of integration between machine, kernel and distro features:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=2267
One issue is that this should generate warnings if the config values
don't make it into the final .config. otherwise they aren't really a
useful mapping of machine -> kernel features (we don't want
"just-in-case" configuration). Obviously the linux-yocto config audit
can warn on things like this, but the fragments need to be tagged as
required (hardware) for that to happen. Which they won't currently be
if specified this way. I'd need to do some tooling work to make that
happen.
Another detail is that KERNEL_FEATURES are applied last. Which means
they can override / enable things that a BSP configuration doesn't
want and could have even explicitly disabled, used different values,
etc.
A proper BSP configuration is already a definition with a curated set
of options, and in a linux-yocto flow, that is typically the first and
last word on the values. doing a lot of BSP configuration via machine
features spreads the logic out to multiple places, which can be a
challenge to track down later. The fact that these map to the
centralized fragments is really good (since while the enablement might
be distributed and spread over recipe space, the actual options are
centralized), but it makes jumping off from a kernel-cache BSP or one
of the qemu references harder, as these will keep showing up .. when
you might not want them.
Yes, we can argue that machine's shouldn't set features that they
don't want to support, but that doesn't cover all of the complications
and potential issues.
If we want to start dabbling with this, these should be a little bit
more opt-in, and be specific to the qemu machines we define (versus
just appending to KERNEL_FEATURES). As for opt-in, I'd suggest
something like an image or machine feature in the spirit of
"DYNAMIC_CONFIG" or "ENABLE_MACHINE_FEATURES", and when that is set,
we do the mapping.
Bruce
>
> # A KMACHINE is the mapping of a yocto $MACHINE to what is built
> --
> 2.30.2
>
>
>
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#171221):
https://lists.openembedded.org/g/openembedded-core/message/171221
Mute This Topic: https://lists.openembedded.org/mt/94009766/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
