From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
"Markus Armbruster" <armbru@redhat.com>,
qemu-devel@nongnu.org, Laurent@vivier.eu,
"Gerd Hoffmann" <kraxel@redhat.com>,
"Philippe Mathieu-Daudé" <f4bug@amsat.org>
Subject: Re: [PATCH 08/11] mos6522: add "info via" HMP command for debugging
Date: Tue, 8 Feb 2022 13:04:44 +0000 [thread overview]
Message-ID: <YgJqbElD7OQM35W7@work-vm> (raw)
In-Reply-To: <2cad9b25-620d-66b9-d64f-7a0e3f806952@ilande.co.uk>
* Mark Cave-Ayland (mark.cave-ayland@ilande.co.uk) wrote:
> On 08/02/2022 10:29, Dr. David Alan Gilbert wrote:
>
> > * Markus Armbruster (armbru@redhat.com) wrote:
> > > Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
> > >
> > > > On 7/2/22 20:34, Peter Maydell wrote:
> > > > > On Thu, 27 Jan 2022 at 21:03, Mark Cave-Ayland
> > > > > <mark.cave-ayland@ilande.co.uk> wrote:
> > > > > >
> > > > > > This displays detailed information about the device registers and timers to aid
> > > > > > debugging problems with timers and interrupts.
> > > > > >
> > > > > > Signed-off-by: Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk>
> > > > > > ---
> > > > > > hmp-commands-info.hx | 12 ++++++
> > > > > > hw/misc/mos6522.c | 92 ++++++++++++++++++++++++++++++++++++++++++++
> > > > > > 2 files changed, 104 insertions(+)
> > > > >
> > > > > I'm not sure how keen we are on adding new device-specific
> > > > > HMP info commands, but it's not my area of expertise. Markus ?
> > > >
> > > > HMP is David :)
> > >
> > > Yes.
> >
> > So let me start with an:
> >
> > Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
> > (If it's useful info for the author of the device, then I'm happy for
> > HMP to have that), but then - (moving the reply around a bit):
> >
> >
> > > Should this be conditional on the targets where we actually link the
> > > device, like info skeys?
> > >
> >
> > Yes, I think so; it's a reasonably old/obscure device, there's no reason
> > everyone having it built in.
>
> Unfortunately that doesn't seem to work: whilst the target CONFIG_* defines
> are declared when processing hmp-commands-info.hx it seems the the device
> CONFIG_* defines are missing?
I'd be happy to take it down to the target level.
Dave
> > > > IIRC it is OK as long as HMP is a QMP wrapper.
> > >
> > > That's "how to do it", and I'll get back to it in a jiffie, but Peter
> > > was wondering about the "whether to do it".
> > >
> > > Most HMP commands are always there.
> > >
> > > We have a few specific to compile-time configurable features: TCG, VNC,
> > > Spice, Slirp, Linux. Does not apply here.
> > >
> > > We have a few specific to targets, such as dump-skeys and info skeys for
> > > s390. Target-specific is not quite the same as device-specific.
> > >
> > > We have no device-specific commands so far. However, dump-skeys and
> > > info skeys appear to be about the skeys *device*, not the s390 target.
> > > Perhaps any s390 target has such a device? I don't know. My point is
> > > we already have device-specific commands, they're just masquerading as
> > > target-specific commands.
> >
> > Yeh we've got info lapic/ioapic as well.
>
> ... which I suspect is a workaround for only the target CONFIG_* defines being declared.
>
> > > The proposed device-specific command uses a mechanism originally made
> > > for modules instead (more on that below).
> > >
> > > I think we should make up our minds which way we want device-specific
> > > commands done, then do *all* of them that way.
> >
> > I think device specific commands make sense, but I think it would
> > probably be better if we had an 'info dev $name' and that a method on
> > the device rather than registering each one separately.
> > I'd assume that this would be a QMP level thing that got unwrapped at
> > HMP.
> >
> > But that's not a problem for this contribution; someone else can figure
> > that out later.
>
>
> ATB,
>
> Mark.
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
next prev parent reply other threads:[~2022-02-08 14:25 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 20:53 [PATCH 00/11] mos6522: switch to gpios, add control line edge-triggering and extra debugging Mark Cave-Ayland
2022-01-27 20:53 ` [PATCH 01/11] mos6522: add defines for IFR bit flags Mark Cave-Ayland
2022-01-27 23:16 ` BALATON Zoltan
2022-02-05 10:51 ` Mark Cave-Ayland
2022-02-05 11:16 ` Philippe Mathieu-Daudé via
2022-02-05 12:06 ` BALATON Zoltan
2022-02-20 10:53 ` Mark Cave-Ayland
2022-02-20 19:21 ` BALATON Zoltan
2022-01-27 20:53 ` [PATCH 02/11] mac_via: use IFR bit flag constants for VIA1 IRQs Mark Cave-Ayland
2022-01-27 20:53 ` [PATCH 03/11] mac_via: use IFR bit flag constants for VIA2 IRQs Mark Cave-Ayland
2022-01-27 20:53 ` [PATCH 04/11] mos6522: switch over to use qdev gpios for IRQs Mark Cave-Ayland
2022-02-07 19:29 ` Peter Maydell
2022-02-20 11:01 ` Mark Cave-Ayland
2022-01-27 20:53 ` [PATCH 05/11] mos6522: remove update_irq() and set_sr_int() methods from MOS6522DeviceClass Mark Cave-Ayland
2022-02-07 19:30 ` Peter Maydell
2022-01-27 20:54 ` [PATCH 06/11] mos6522: use device_class_set_parent_reset() to propagate reset to parent Mark Cave-Ayland
2022-02-07 19:31 ` Peter Maydell
2022-01-27 20:54 ` [PATCH 07/11] mos6522: add register names to register read/write trace events Mark Cave-Ayland
2022-02-07 19:32 ` Peter Maydell
2022-01-27 20:54 ` [PATCH 08/11] mos6522: add "info via" HMP command for debugging Mark Cave-Ayland
2022-02-07 19:34 ` Peter Maydell
2022-02-08 5:14 ` Philippe Mathieu-Daudé via
2022-02-08 8:10 ` Markus Armbruster
2022-02-08 10:29 ` Dr. David Alan Gilbert
2022-02-08 11:52 ` Daniel P. Berrangé
2022-02-08 12:43 ` Mark Cave-Ayland
2022-02-08 13:03 ` Dr. David Alan Gilbert
2022-02-08 15:13 ` Markus Armbruster
2022-02-08 12:32 ` Mark Cave-Ayland
2022-02-08 13:04 ` Dr. David Alan Gilbert [this message]
2022-02-08 11:38 ` Daniel P. Berrangé
2022-02-08 12:39 ` Mark Cave-Ayland
2022-02-08 12:49 ` Daniel P. Berrangé
2022-02-08 13:06 ` Mark Cave-Ayland
2022-02-08 13:10 ` Daniel P. Berrangé
2022-02-20 17:18 ` Mark Cave-Ayland
2022-02-21 12:20 ` Philippe Mathieu-Daudé
2022-02-21 22:27 ` Mark Cave-Ayland
2022-02-21 17:11 ` Daniel P. Berrangé
2022-02-21 22:29 ` Mark Cave-Ayland
2022-02-22 15:03 ` Dr. David Alan Gilbert
2022-02-24 12:26 ` Mark Cave-Ayland
2022-01-27 20:54 ` [PATCH 09/11] mos6522: record last_irq_levels in mos6522_set_irq() Mark Cave-Ayland
2022-01-27 20:54 ` [PATCH 10/11] mos6522: implement edge-triggering for CA1/2 and CB1/2 control line IRQs Mark Cave-Ayland
2022-01-27 20:54 ` [PATCH 11/11] macio/pmu.c: remove redundant code Mark Cave-Ayland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YgJqbElD7OQM35W7@work-vm \
--to=dgilbert@redhat.com \
--cc=Laurent@vivier.eu \
--cc=armbru@redhat.com \
--cc=f4bug@amsat.org \
--cc=kraxel@redhat.com \
--cc=mark.cave-ayland@ilande.co.uk \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).