On Mon, 10 Aug 2026 at 16:55, Pierrick Bouvier
<[email protected]> wrote:
>
> On 8/10/2026 8:46 AM, Peter Maydell wrote:
> > On Fri, 24 Jul 2026 at 01:09, Pierrick Bouvier
> > <[email protected]> wrote:
> >>
> >> Now that we can link a single-binary with at least two targets (arm,
> >> aarch64),
> >> we want to make sure that we expose the same set of machines (later
> >> devices and
> >> cpus) than target binaries. For that, we implemented a static filtering
> >> based on
> >> target interfaces that each machine will implement to declare which
> >> targets have
> >> this machine.
> >>
> >> However, we discovered that this static filtering is not enough. Indeed,
> >> some
> >> machines and devices do not depend only on target, and their presence can
> >> depend
> >> on Kconfig or host/target combination. Thus, our static approach can't
> >> work, and
> >> we need something more flexible.
> >
> > Do you have some specific examples of where the static filtering isn't
> > sufficient? I can certainly believe that we have some at the moment,
> > but I'm curious about how much of that is "just by accident because
> > ifdefs were the easy thing to do" versus when the filtering makes
> > sense for avoiding showing the user things that won't work.
> As you can see in the series, machines nitro and x-remote are concerned
> (they depend on host/guest combination - summarized by a target config
> entry). There are additional devices I found also (igpd bus, plus nitro
> devices), but I wanted to validate approach on machines first.
> I didn't observe any cpu (yet) that needs this extra flexibility.
> This is only for arm/aarch64 combination, I expect we'll have other
> cases as we add new archs in single-binary.
>
> Also, there is a benefit to register *all* types and filter them
> afterward: we can identify conflicting QOM types with any combination,
> and not only depending on which targets gets enabled.
> Finally, this approach is much less verbose than adding an if (cond) {}
> on every type_register_static location.
>
> Do you have an alternative suggestion that would retain all those
> benefits, but would be better in your option?
No, I'm not particularly strongly opinionated about the approach,
I was just trying to understand the background motivation for it.
thanks
-- PMM
