Re: [Qemu-devel] [PATCH 0/6] Device state visualization reloaded

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, Sep 07, 2011 at 11:37:20AM +0200, Kevin Wolf wrote:
> Am 06.09.2011 19:05, schrieb Michael S. Tsirkin:
> > On Tue, Sep 06, 2011 at 11:28:09AM -0500, Anthony Liguori wrote:
> >> On 09/06/2011 11:09 AM, 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?
> >>
> >> $ virsh human-monitor-passthrough GuestName device_show foo
> >>
> >> Should work.
> > 
> > So how, in the end, will user know it's unsupported?
> > I don't agree with 'all HMP is unstable' as people
> > will use it and will come to depend on it.
> 
> Why unsupported? It's just not a stable API to script against. It's a
> user interface, not a programming interface. So as long as you use it
> manually, that's perfectly fine.
> 
> Would you expect that virt-manager never changes its GUI because there
> might be some scripts that try to achieve things by screen scraping? The
> interface is just not meant for such uses, and if you use it in that way
> and it breaks with the next version it's your own fault.
> 
> Kevin

I certainly think that radically changing a GUI is very bad usability.
Screen scarping is a silly example, but documentation does appear
e.g. on the web, and GUI changes invalidate it. I won't mention
recent examples of user unhappiness - it takes years to live down
such trauma.

If we expose qemu internals in a command, that's a very
bad idea to give such command to the user, because
1. users will come to depend on the command, whatever you tell them
2. the fact it's there means there is some unaddressed need,
   so we plaster over it with unsupported commands instead
   of addressing it properly

But if the command is not for users at all, if it's
for qemu debugging, then exposing internals is a very
logical thing.  Only problem is - we must make it very very clear
which commands are for qemu debugging.

-- 
MST