On Fri, Mar 08, 2024 at 04:19:42PM +0100, Markus Armbruster wrote:
The coupling with the main QAPI schema is unfortunate.
The purpose of docs/interop/firmware.json is to serve as schema for
firmware descriptions: a firmware description is a JSON object that
conforms to this schema's struct Firmware.
Such a description should be installed along with each firmware binary.
QAPI tooling can be used to check conformance: parse the firmware
description JSON object, feed it to the generated visit_type_Firmware().
Success implies conformance.
If you find more uses for the C struct Firmware created by
visit_type_Firmware(), more power to you.
firmware.json needs machine.json for SysEmuTarget, and block-core.json
for BlockdevDriver. The largest and the third-largest QAPI module just
for two enums. Almost a quarter Mebibyte of code.
firmware.json can use BlockdevDriver, but we could question
whether it /should/ use BlockdevDriver. Is there really a
compelling reason to support every possible block driver for
readonly firmware and tiny nvram file ? I thin kit would be
totally reasonable to define a "FirmwareFormat" enum which
only permitted 'raw' and 'qcow2'. If someone wants to
justify why we need another format, I'm all ears...
For SysEmuTarget its a little more useful, as in theory the
firmware could be extended to any QEMU target. In practice
thus far we've only used it todescribe EFI based firmware,
which is relevant for a subset of targets. It doesn't seem
to be a huge downside to define a FirmwareTarget enum with
only the arches we've actually got a use for so far. When
someone comes along with a need for non-EFI we can extend
it, and we'll need to extend libvirt at the same time anyway
qapi-gen.py generates more than 12kSLOC. Without the include (and with
the enums dumbed down to 'str' to enable that), it generates less than
800.
We could use Sphinx to generate a manual from firmware.json's document.
Except that manual would be useless, because of its 11,000 lines of
HTML, less than 800 are for firmware.json.