Re: [PATCH v2] Add -build-info and -build-info-json CLI arguments

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

On Mon, Sep 23, 2024 at 10:09:32PM +0300, Manos Pitsidianakis wrote:
> Hello Daniel,
> 
> On Mon, 23 Sep 2024 19:45, "Daniel P. Berrangé" <berrange@redhat.com> wrote:
> > On Mon, Sep 23, 2024 at 09:05:24AM +0300, Manos Pitsidianakis wrote:
> > > Add -build-info and -build-info-json CLI arguments for human and machine
> > > readable output of build/compile-time configuration data. The source for
> > > this data is the meson generated config-host.h.
> > > 
> > > This information is mainly of interest to developers and other folk who
> > > deal with many different builds of QEMU and need a way to properly
> > > differentiate them.
> > > 
> > > Because there's always the chance someone will want to consume an
> > > interface programmatically, also add a -json option that does the same
> > > but outputs a machine-readable JSON object.
> > 
> > This turns our build system configuration information into a
> > defacto public API, and while its using JSON, it isn't yusing
> > QAPI.
> > 
> > To some degree we leak our build system config names externally
> > because the "if" stanzas in the QAPI schema get copied into the
> > docs.
> > 
> > Overall though I don't think we should be exposing this build
> > config infomation externally. We've had many times, particularly
> > with testing, where people have wanted to access CONFIG_XXX info
> > about a QEMU binary, but IIRC we've always steered people towards
> > querying for the actual feature they want, rather than looking
> > at CONFIG_XXX settings.
> > 
> > ie, look a query-audiodevs to discover what audio baxckends are
> > built-in, don't look for CONFIG_XXX settings related to audio.
> > If there are gaps in information we can query from QMP, we should
> > aim to close those gaps.
> > 
> > IOW, I don't think we should expose this build info info in either
> > human readable or machine readable format.
> 
> QAPI/QMP is not the perspective of this patch, this is for people who use
> custom-built (i.e. not from a distro) binaries and want to be able to
> identify how it was built. Launching a binary to query stuff is
> unnecessarily complex for this task, and the info is not generally
> interesting to the API consumers as you said.

Launching QEMU to talk QMP is our defined public API for querying
anything about the capabilities of QEMU. We're worked hard to get
away from providing ad-hoc ways to query QEMU from the command
line and going back to that is not desirable. It may be slightly
more complicated, but not by very much.

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 :|