Hello Daniel, On Tue, 24 Sept 2024 at 11:45, Daniel P. Berrangé <berra...@redhat.com> wrote: > > 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é" <berra...@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.
Again, this is not a "capabilities discovery" API. It lists the build-time configuration of the binary. Perhaps we can expose it in a different way so that people don't end up confused? Manos -- Manos Pitsidianakis Emulation and Virtualization Engineer at Linaro Ltd
