On Wed, Mar 11, 2026 at 13:14:41 +0000, Daniel P. Berrangé via Devel wrote: > On Wed, Mar 11, 2026 at 02:05:24PM +0100, Markus Armbruster wrote:
[...] > For -object / object_add we introduced formal QAPI modelling of > all Object subclasses which implement the UserCreatable interface. > IIUC, that gives us the desired separation between internal and > external views, as only properties declared in qapi/qom.json are > publically settable. > > This work did not apply to the Device classes because the historical > baggage with qdev being grafted onto qom, means we don't have that > working via the UserCreatable inteface or -object/object_add. > > Can we bring Device into the same world though ? > > Adding 1000 device types to QAPI is a huge job, so it would need to > be a long incremental job, unless perhaps we auto-generate QAPI > descriptions for everything that already exists ? When I was converting libvirt to use the JSON syntax for -device I've used the output of -device DEVTYPE,? to figure out the required types. From what I've observed, in the vast majority of casesthe type that qemu wants is already reported, thus generating the schema for it should be feasible. Obviously majority of the options lack any form of description so documentation would be a much bigger problem, but there would be already an starting point. Anyways for anyone wanting to actually do this libvirt's qemuxmlconftest suite could be useful here as it contains a sizable portion of options libvirt supports (I'ts extremely likely that we don't cover some corner cases though). In addition the testsuite can actually perform validation of any of the commands taking JSON against the monitor schema, To validate that everything that libvirt covers by tests is present in the schema for 'device_add' one would need to just change 1 boolean (to force full schema validation for device_add) and add a schema dump.
