[2/4] conf/fragments: add fragments for qemux86-64 and qemuarm64

From: Alexander Kanavin <alex@linutronix.de>

These will be used by official bitbake-setup configurations,
and so let's start with them :) Plenty more fragments can
be added over time.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/conf/fragments/machines/qemuarm64.conf  | 5 +++++
 meta/conf/fragments/machines/qemux86-64.conf | 5 +++++
 2 files changed, 10 insertions(+)
 create mode 100644 meta/conf/fragments/machines/qemuarm64.conf
 create mode 100644 meta/conf/fragments/machines/qemux86-64.conf

On Tue, 2025-06-03 at 13:35 +0200, Alexander Kanavin via lists.yoctoproject.org wrote:
> From: Alexander Kanavin <alex@linutronix.de>
> 
> These will be used by official bitbake-setup configurations,
> and so let's start with them :) Plenty more fragments can
> be added over time.
> 
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>  meta/conf/fragments/machines/qemuarm64.conf  | 5 +++++
>  meta/conf/fragments/machines/qemux86-64.conf | 5 +++++
>  2 files changed, 10 insertions(+)
>  create mode 100644 meta/conf/fragments/machines/qemuarm64.conf
>  create mode 100644 meta/conf/fragments/machines/qemux86-64.conf
> 
> diff --git a/meta/conf/fragments/machines/qemuarm64.conf b/meta/conf/fragments/machines/qemuarm64.conf
> new file mode 100644
> index 00000000000..0fc164541d5
> --- /dev/null
> +++ b/meta/conf/fragments/machines/qemuarm64.conf
> @@ -0,0 +1,5 @@
> +BB_CONF_FRAGMENT_SUMMARY = "Use qemuarm64 as a target MACHINE, suitable for running in QEMU system emulator."
> +BB_CONF_FRAGMENT_DESCRIPTION = "Select qemuarm64 as the target machine. This is the best option for running the target system inside QEMU emulator on arm64 build hosts, \
> +as it allows near-native performance with kvm acceleration. Also useful for testing arm64 specific assembly code or compiler output."
> +
> +MACHINE ?= "qemuarm64"
> diff --git a/meta/conf/fragments/machines/qemux86-64.conf b/meta/conf/fragments/machines/qemux86-64.conf
> new file mode 100644
> index 00000000000..0fce37c4e2e
> --- /dev/null
> +++ b/meta/conf/fragments/machines/qemux86-64.conf
> @@ -0,0 +1,5 @@
> +BB_CONF_FRAGMENT_SUMMARY = "Use qemux86-64 as a target MACHINE, suitable for running in QEMU system emulator."
> +BB_CONF_FRAGMENT_DESCRIPTION = "Select qemux86-64 as the target machine. This is the best option for running the target system inside QEMU emulator on x86-64 build hosts, \
> +as it allows near-native performance with kvm acceleration. Also useful for testing x86-64 specific assembly code or compiler output."
> +
> +MACHINE ?= "qemux86-64"

What bothers me about this is that we have multiple files, each with a
single similar config line in them. It implies we need to create a new
machine config fragment for every machine, which to be honest, is
madness.

Would it be better if the config/setup code understood what something
like "machine/qemux86-64" or "distro/poky" meant and did something
magic with that?

Cheers,

Richard

On Tue, 3 Jun 2025 at 21:48, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:

> What bothers me about this is that we have multiple files, each with a
> single similar config line in them. It implies we need to create a new
> machine config fragment for every machine, which to be honest, is
> madness.
>
> Would it be better if the config/setup code understood what something
> like "machine/qemux86-64" or "distro/poky" meant and did something
> magic with that?

Haha, yes. I've been stuck in the subject so long that I no longer see
the forest for the trees.

I think bitbake-config-build should be extended to have
'list-machines/set-machine/list-distros/set-distro', and then
bitbake-setup would call out to that, like it already does for
fragments. There's already 'show-machines' in bitbake-layers, which
should be renamed and moved, so that bitbake-layers is less
over-stuffed with sub-commands.

Alex

On Wed, 2025-06-04 at 09:46 +0200, Alexander Kanavin wrote:
> On Tue, 3 Jun 2025 at 21:48, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> 
> > What bothers me about this is that we have multiple files, each
> > with a
> > single similar config line in them. It implies we need to create a
> > new
> > machine config fragment for every machine, which to be honest, is
> > madness.
> > 
> > Would it be better if the config/setup code understood what
> > something
> > like "machine/qemux86-64" or "distro/poky" meant and did something
> > magic with that?
> 
> Haha, yes. I've been stuck in the subject so long that I no longer
> see the forest for the trees.

It is hard when you're deeply into something like this! Something has
bothered me about these for a while but it has taken me far too long to
be able to succinctly explain it.

> I think bitbake-config-build should be extended to have
> 'list-machines/set-machine/list-distros/set-distro', and then
> bitbake-setup would call out to that, like it already does for
> fragments. There's already 'show-machines' in bitbake-layers, which
> should be renamed and moved, so that bitbake-layers is less
> over-stuffed with sub-commands.

Maybe. I do like the idea of being able to express a configuration with
just a list of fragments so a magic mapping of machine/XXX and
distro/XXX does still have some appeal. We could code something:

BBCONFIG_FRAGMENT_VARIABLE_MAPS = "machine/:MACHINE and distro/:DISTRO"

to make the code generic?

Cheers,

Richard

On Wed, 4 Jun 2025 at 10:48, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> > I think bitbake-config-build should be extended to have
> > 'list-machines/set-machine/list-distros/set-distro', and then
> > bitbake-setup would call out to that, like it already does for
> > fragments. There's already 'show-machines' in bitbake-layers, which
> > should be renamed and moved, so that bitbake-layers is less
> > over-stuffed with sub-commands.
>
> Maybe. I do like the idea of being able to express a configuration with
> just a list of fragments so a magic mapping of machine/XXX and
> distro/XXX does still have some appeal. We could code something:
>
> BBCONFIG_FRAGMENT_VARIABLE_MAPS = "machine/:MACHINE and distro/:DISTRO"
>
> to make the code generic?

My idea was to do away with fragments for machine/distro, and have
'bitbake-config-build set-machine XXX' write 'MACHINE = 'XXX' into
conf/auto.conf.

And then bitbake-setup config files would have a particular syntax for
that, e.g. replace the current:

            "qemux86-64-poky": {
                "description": "Poky reference distro build for qemux86-64",
                "oe-template": "poky-blank",
                "oe-fragments":
["core/machines/qemux86-64","yocto/distros/poky","core/yocto/sstate-mirror-cdn","core/qemu/enable-native-sdl"],
                "targets": ["bitbake core-image-minimal
core-image-full-cmdline core-image-sato-sdk core-image-weston"]
            },

with

          "qemux86-64-poky": {
                "description": "Poky reference distro build for qemux86-64",
                "oe-template": "poky-blank",
                "oe-distro": "poky",
                "oe-machine": "qemux86-64",
                "oe-fragments":
["core/yocto/sstate-mirror-cdn","core/qemu/enable-native-sdl"],
                "targets": ["bitbake core-image-minimal
core-image-full-cmdline core-image-sato-sdk core-image-weston"]
            },

I don't have a strong opinion either way, perhaps it's best to 'upload
discussion data in brain and process', while fixing further do_unpack
rework fails :) If you can respond with further points I'd appreciate
that! (so I better see the forest)

Alex

On Wed, 2025-06-04 at 11:05 +0200, Alexander Kanavin wrote:
> On Wed, 4 Jun 2025 at 10:48, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > > I think bitbake-config-build should be extended to have
> > > 'list-machines/set-machine/list-distros/set-distro', and then
> > > bitbake-setup would call out to that, like it already does for
> > > fragments. There's already 'show-machines' in bitbake-layers, which
> > > should be renamed and moved, so that bitbake-layers is less
> > > over-stuffed with sub-commands.
> > 
> > Maybe. I do like the idea of being able to express a configuration with
> > just a list of fragments so a magic mapping of machine/XXX and
> > distro/XXX does still have some appeal. We could code something:
> > 
> > BBCONFIG_FRAGMENT_VARIABLE_MAPS = "machine/:MACHINE and distro/:DISTRO"
> > 
> > to make the code generic?
> 
> My idea was to do away with fragments for machine/distro, and have
> 'bitbake-config-build set-machine XXX' write 'MACHINE = 'XXX' into
> conf/auto.conf.

Let me just throw some ideas around here. I'm not saying any are
right/wrong, this is in the spirit of sharing ideas.

Moving the "machine" commands into one standard place would make sense
so I do like that aspect of what you're suggesting.

I have some caution about teaching "bitbake" commands machine/distro
specific as it breaks layers of separation. Note that bitbake-layers
list-machines is part of OE-Core, not bitbake.

I also have an idea in the back of my mind that being able to reproduce
common setups with a list of fragments would be a nice idea. If you
have to say:

set-machine XXX
set-distro YYY
set-features A B C

it isn't a very succinct explanation to people. If you can say:

set-features A B C machine/XXX distro/YYY

then it becomes a bit of a nicer thing for someone else to copy. This
is all generic in that someone else can add their own fragments. The
autobuilder can also then simplify configs too. Someone could add an
extra variable mapping for an extra level of config, say
toolchain/clang to set TOOLCHAIN = "clang", not that I'm suggesting
that specifically but you get the idea.

> And then bitbake-setup config files would have a particular syntax for
> that, e.g. replace the current:
> 
>             "qemux86-64-poky": {
>                 "description": "Poky reference distro build for qemux86-64",
>                 "oe-template": "poky-blank",
>                 "oe-fragments":
> ["core/machines/qemux86-64","yocto/distros/poky","core/yocto/sstate-mirror-cdn","core/qemu/enable-native-sdl"],
>                 "targets": ["bitbake core-image-minimal
> core-image-full-cmdline core-image-sato-sdk core-image-weston"]
>             },
> 
> with
> 
>           "qemux86-64-poky": {
>                 "description": "Poky reference distro build for qemux86-64",
>                 "oe-template": "poky-blank",
>                 "oe-distro": "poky",
>                 "oe-machine": "qemux86-64",
>                 "oe-fragments":
> ["core/yocto/sstate-mirror-cdn","core/qemu/enable-native-sdl"],
>                 "targets": ["bitbake core-image-minimal
> core-image-full-cmdline core-image-sato-sdk core-image-weston"]
>             },
> 
> I don't have a strong opinion either way, perhaps it's best to 'upload
> discussion data in brain and process', while fixing further do_unpack
> rework fails :) If you can respond with further points I'd appreciate
> that! (so I better see the forest)

playing devils advocate:

          "qemux86-64-poky": {
                "description": "Poky reference distro build for qemux86-64",
                "oe-template": "poky-blank",
                "oe-fragments": ["core/yocto/sstate-mirror-cdn","core/qemu/enable-native-sdl", "machine/qemux86-64 distro/poky],
                "targets": ["bitbake core-image-minimal core-image-full-cmdline core-image-sato-sdk core-image-weston"]
            },

Cheers,

Richard