Re: [Buildroot] [PATCH 2/3] package/qemu: select FDT for custom targets too

From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: Carlos Santos <unixmania@gmail.com>
Cc: Thomas Huth <huth@tuxfamily.org>,
	Romain Naour <romain.naour@gmail.com>,
	buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 2/3] package/qemu: select FDT for custom targets too
Date: Sat, 5 Nov 2022 22:18:57 +0100	[thread overview]
Message-ID: <20221105221857.5567e63f@windsurf> (raw)
In-Reply-To: <CAJ4jsacyrm_vy13vFbX0sR9K991LeVa=iJsQeevo_V9+OkSA_g@mail.gmail.com>

On Sat, 5 Nov 2022 17:23:53 -0300
Carlos Santos <unixmania@gmail.com> wrote:

> BR2_PACKAGE_QEMU_CUSTOM_TARGETS is a string, so adding a "select
> BR2_PACKAGE_QEMU_FDT" does not have any effect.
> 
> A better solution for the case in which only linux-user targets are
> selected requires a more complex approach. I will submit a separate
> patch for this purpose. Meanwhile, let's put this series on hold.

Hm, I think I start to understand the issue, and with the current
organization of the Config.in options in package/qemu/Config.in, it's
going to be difficult to fix in a correct way.

For example, it looks like the linux-user mode emulation doesn't work
with the musl C library:

config BR2_PACKAGE_QEMU_LINUX_USER
        bool "Enable all Linux user-land emulation"
        # Incompatible "struct sigevent" definition on musl
        depends on !BR2_TOOLCHAIN_USES_MUSL

So, it means that BR2_PACKAGE_QEMU_CUSTOM_TARGETS="i386-linux-user"
will in fact fail to build with a musl toolchain...

I only sane way to address this I believe would be to remove
BR2_PACKAGE_QEMU_CUSTOM_TARGETS entirely, and instead have
BR2_PACKAGE_QEMU_SYSTEM_TARGETS and
BR2_PACKAGE_QEMU_LINUX_USER_TARGETS, which would only be accessible
when BR2_PACKAGE_QEMU_SYSTEM or BR2_PACKAGE_QEMU_LINUX_USER
respectively are enabled. When BR2_PACKAGE_QEMU_SYSTEM_TARGETS is
empty, all system emulation targets are built, otherwise only the
specified ones are built. Ditto for the user emulation targets.

Obviously as usual, the main drawback is that is breaks backward
compatibility with existing configurations...

The other approach, which you took, is to assume for the "worst", and
assume that when BR2_PACKAGE_QEMU_CUSTOM_TARGETS != "", we might build
system or user emulation targets, and therefore this option needs to
have the combination of the dependencies of the system and user
emulation options.... which would mean disabling this option with musl
toolchains, for example.

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot