Re: [PATCH RFC 00/10] qapi: remove all TARGET_* conditionals from the schema

["Daniel P. Berrangé" <berrange@redhat.com>]

On Thu, May 08, 2025 at 04:56:03PM +0200, Philippe Mathieu-Daudé wrote:
> On 8/5/25 15:58, Daniel P. Berrangé wrote:
> > Pierrick has proposed a series that introduces a concept of runtime
> > conditionals to the QAPI schema, in order to adapt the TARGET_*
> > conditionals currently used at build time:
> > 
> >    https://lists.nongnu.org/archive/html/qemu-devel/2025-05/msg01699.html
> > 
> > For the sake of comparison & evaluation, this series illustrates the
> > alternative approach that we've discussed of entirely removing any
> > concept of TARGET_* conditionals.
> > 
> > With this the QAPI schema varies solely based on CONFIG_* conditionals,
> > and is thus invariant across different target emulators.
> > 
> > In this PoC I've taken the minimal effort approach to the problem.
> > 
> > The QAPI schema has removed the TARGET_* conditionals and in order to
> > make all the emulators then compile, the stubs/ directory is populated
> > with a bunch of files to provide dummy impls of the target specific QMP
> > commands.
> > 
> > This is sufficient to make the current QEMU binaries build successfully.
> > 
> > To make the "single binary" concept work, however, would require
> > additional followup work to eliminate the stubs.
> > 
> > Instead of having stubs we would need to de-couple the QMP command
> > impl from the machine internals. This would likely require greater
> > use of interfaces and/or virtual method dispatchers on the machine
> > class. This would enable the 'qmp_XXXXX' command impls to exist
> > once. Then they call out to virtual methods on the machine to provide
> > the real impl, and/or generate an error if the virtual method is not
> > implemented for the machine.
> 
> Note,  I don't see commands "per machine", but per device (including
> CPU). When not specified, we iterate over device implementations / CPUs.

Yep, that makes sense. If its not abstracted via machines, we'll need
to abstract it in some other place in our object model. The right answer
probably varies depending on each feature/command we're considering


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|