On 2011-09-06 18:09, Michael S. Tsirkin wrote: > On Tue, Sep 06, 2011 at 10:51:26AM -0500, Anthony Liguori wrote: >> On 09/06/2011 10:45 AM, Jan Kiszka wrote: >>> On 2011-09-06 16:48, Michael S. Tsirkin wrote: >>>> I'm afraid that won't be enough to stop people >>>> scripting this command - libvirt accessed >>>> HMP for years. >>>> >>>> On the other hand, no QMP command means e.g. >>>> libvirt users don't get any benefit from this. >>>> >>>> What I think will solve these problems, for both HMP and QMP, >>>> is an explicit 'debug_unstable' or 'debug_unsupported' command that will >>>> expose all kind of debugging functionality making it >>>> very explicit that it's an unsupported debugging utility. >>>> >>>> Proposed syntax: >>>> >>>> debug_unstable<subcommand> <options> >>>> >>>> Example: >>>> >>>> debug_unstable device_show -all >>> >>> For HMP, this would needlessly complicate the user interface, nothing I >>> would support. People scripting things on top of HMP are generally doing >>> this on their own risk and cannot expect output stability. >>> >>> device_show is like info qtree: the output will naturally change as the >>> emulated hardware evolves, information is added/removed, or we simply >>> improve the layout. Recent changes on info network are an example for >>> the latter. >> >> Yeah, I'm not worried about stability. HMP commands that aren't >> exposed as QMP commands are inherently unstable and should not be >> scripted to. > > They are also not accessible when using libvirt, right? > Which means almost all cases I care about: debugging on my laptop > I can easily attach with gdb and inspect state.
HMP passthrough or - I bet that's what you rather want - monitor passthrough from gdb. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux
