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

[Markus Armbruster]

"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.

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.

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?

Separate discussion, does not block this series.