Re: [Qemu-devel] Abandon our QMP first policy? (was: [PATCH v3 5/7] hmp: Add info commands for preconfig)

[Dr. David Alan Gilbert]

* Markus Armbruster (address@hidden) wrote:
> "Dr. David Alan Gilbert" <address@hidden> writes:
> 
> > * Markus Armbruster (address@hidden) wrote:
> >> Gerd Hoffmann <address@hidden> writes:
> >> 
> >> >   Hi,
> >> >
> >> >> > Now let's review the three commands:
> >> >> > 
> >> >> > * Gerd, why does "info usbhost" have no QMP equivalent?
> >> >
> >> > Works only when running qemu directly, in the libvirt sandbox qemu
> >> > hasn't the permissions needed to scan the host usb bus so that would be
> >> > rather pointless ...
> >> 
> >> I don't think this meets either of the two criteria:
> >> 
> >> * I meets "makes no sense in QMP" only if QMP implies "can't scan host
> >>   USB bus".  Libvirt implies it, but QMP doesn't imply libvirt; it's its
> >>   most important, not its sole user.
> >> 
> >> * It meets "of use only for human users" only if we're convinced it's of
> >>   no use to programs.
> >> 
> >>   To avoid speculation and endless arguments about what could or could
> >>   not be of use, we've always stuck to "when in doubt, assume it could
> >>   be of use".
> >> 
> >>   "Libvirt can't use it" falls short.
> >> 
> >>   "Any management application worth anything would deny QEMU the
> >>   capability to scan the USB host bus, and thus wouldn't be able to use
> >>   it" is exactly the argument we intended to avoid.
> >> 
> >> QMP falling short of completeness in relatively unimportant ways like
> >> this one isn't exactly terrible.  The most serious effect is probably
> >> serving as a bad example that leads to further arguments like this one.
> >> These are well worth avoiding, though.
> >
> > Markus:
> >   a) This is a separate discussion; info usbhost has been there for many
> > years;  this patch set doesn't change that.
> 
> Yes, it's separate.
> 
> >   b) From HMP, if someone wants to add a command like 'info usbhost' to
> > make their debugging of USB easy, then HMP is all for that and there's
> > no way I'm going to require QMP implementations for a debug command.
> 
> As I said before, said someone is welcome to make his case for why the
> command is of use only for human users in the commit message.
> 
> If the QMP maintainer gets a say in judging that case, good.
> 
> But if your "no way" means what I have to assume it means, namely "no
> way I'm taking no for an answer", then we're at an impasse.
> 
> Evolving HMP without consideration for QMP's mission makes carrying out
> that mission harder.  Specifically, me having to watch for new HMP
> commands bypassing QMP, then judge and maybe debate whether that's okay
> is beyond my capacity.  The debate part in particular.  I expect to fail
> as a QMP maintainer in that case.

I feel currently I have exactly the same problem as an HMP maintainer,
since it seems impossible to get small changes in without tripping over
QMP.

> Avoiding QMP maintenance balloon out of control was one of our reasons
> for the rule "HMP commands must be implemented in terms of QMP".  We pay
> a modest amount of extra developer effort for a much-needed
> simplification of the maintainers' job.
> 
> Regarding "modest amount of effort": I already told you I'm prepared to
> back that claim with patches whenever requiring QMP blocks HMP patches.
> If that can't shake your conviction that requiring QMP is impractical, I
> figure nothing will.
> 
> Ways out of the impasse:
> 
> 1. Find a more capable maintainer for QMP (MAINTAINERS sections QMP and
> QAPI Schema).  To give you an idea of the work involved, almost 10% of
> the commits in 2.9 touched the latter.

I had considered asking the same question for HMP; but the only reason I
didn't is because I don't want HMP to die.

> 2. Split the work differently: make the HMP maintainer responsible for
> keeping QMP complete.
> 
> 3. Abandon QMP's goal to be complete.  Tell management applications to
> use HMP where QMP falls short.
> 
> To be brutally frank, 2. requires more trust in your willingness to care
> about QMP than I have right now.
> 
> By refusing to cooperate, you can force 3.
> 
> The solution most conducive to my personal well-being is probably 1.
> 
> Any other bright ideas?

IMHO the problem is that 'QMP be complete' is a fine goal but you're
applying it too strongly by not giving me the trust that I *DO* have the
willingness to care for QMP - but to be able to make reasonable
decisions for cases that really are debugging tools.

I strongly agree that all management tools should be using QMP, and
anything that they need should always be added to QMP (whether or
not they're also added to HMP, I'd prefer if they are, but I'm not
going to stop QMP only commands).

Look at this series; all it did was enable long standing existing HMP 'info'
commands to be used in the new context.  I chose only the info commands
because they looked like the type of thing developers would want to be
able to see the current state of qemu; I carefully did not enable
anything that changed the state.

How was any of that 'Abandoning QMP's goal to be complete'?

The way I see it, this series just fixes the HMP breakage in preconfig
mode - because I care that HMP doesn't decay.

HMP is for debugging and easy use;  my judgement is that if the
developer of a device/subsection wants a command to make their
life easier when debugging then I'm happy for them to add it to HMP.
I want it to be simple and easy for those devs to be able to add
that debug.

But I'll only allow that as an HMP command if it's clearly
a convenient debugging tool rather than implementing some new feature
that should be in QMP.

> Separate discussion, does not block this series.

Good; please let me know if there are any other changes needed in this
series.

Dave

--
Dr. David Alan Gilbert / address@hidden / Manchester, UK