On Tue, 11 Jun 2024 at 09:11, Mark Cave-Ayland <mark.cave-ayl...@ilande.co.uk> wrote: > > On 11/06/2024 06:49, Markus Armbruster wrote: > > > Philippe Mathieu-Daudé <phi...@linaro.org> writes: > > > >> Officialise the QMP command, use the existing > >> hmp_info_human_readable_text() helper. > > > > I'm not sure "officialise" is a word :) > > > > Taking a step back... "info via" and its new QMP counterpart > > x-query-mos6522-devices dump device state. I understand why examining > > device state via monitor can be useful for debugging. However, we have > > more than 2000 devices in the tree. Clearly, we don't want 2000 device > > state queries. Not even 100. Could we have more generic means instead? > > > > We could use QOM (read-only) properties to expose device state. > > > > If we use one QOM property per "thing", examining device state becomes > > quite tedious. Also, you'd have to stop the guest to get a consistent > > view, and adding lots of QOM properties bloats the code. > > > > If we use a single, object-valued property for the entire state, we get > > to define the objects in QAPI. Differently tedious, and bloats the > > generated code. > > > > We could use a single string-valued property. Too much of an abuse of > > QOM? > > > > We could add an optional "dump state for debugging" method to QOM, and > > have a single query command that calls it if present. > > > > Thoughts? > > I agree that there should be a better way of doing things here. The aim of the > original "info via" series was to allow the command to be contained > completely within > mos6522.c, but unfortunately due to the way that qemu-options.hx works then > you end > up with #ifdef-fery or stubs to make all configuration combinations work. > > As you point out ideally there should be a way for a QOM object to dynamically > register its own monitor commands, which I think should help with this. > > IIRC in the original thread Daniel or David proposed a new "debug" monitor > command > such that a device could register its own debug <foo> commands either via > DeviceClass > or a function called during realize that would return a HumanReadableText via > QMP.
This is starting to sound like OOP: A Monitor interface defines monitor commands, and QOM type classes can implement/define their own. A Debug interface would do this.
