Re: Examining device state via monitor for debugging

[Manos Pitsidianakis]

On Tue, 11 Jun 2024 at 09:11, Mark Cave-Ayland
<mark.cave-ayland@ilande.co.uk> wrote:
>
> On 11/06/2024 06:49, Markus Armbruster wrote:
>
> > Philippe Mathieu-Daudé <philmd@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.