All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>
Cc: Eric Blake <eblake@redhat.com>,
	qemu-devel@nongnu.org, dgilbert@redhat.com,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu
Date: Fri, 15 Dec 2017 14:56:18 +0100	[thread overview]
Message-ID: <87ind8nlh9.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <949be39f-d2a9-29b4-d9b7-46378d827161@linux.vnet.ibm.com> (Daniel Henrique Barboza's message of "Thu, 14 Dec 2017 17:46:15 -0200")

Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com> writes:

> On 12/14/2017 01:21 PM, Markus Armbruster wrote:
>> Eric Blake <eblake@redhat.com> writes:
>>
>>> On 12/13/2017 12:15 PM, Daniel Henrique Barboza wrote:
>>>> Commit 755f196898 ("qapi: Convert the cpu command") added the qmp_cpu
>>>> function in qmp.c, leaving it blank. It the same commit, a working
>>>> hmp_cpu was implemented. Since then, no further changes were made in
>>>> qmp_cpu, resulting now in a working 'cpu' command that works in HMP
>>>> and a 'cpu' command in QMP that does nothing.
>>>>
>>>> Regardless of what constraints were involved that time in not implemeting
>>>> qmp_cpu, at this moment it is possible to have both.
>> If I remember that part of history correctly, implementing the command
>> in QMP was just as possible back then, but deemed a Bad Idea for the
>> reason Eric explains below.
>>
>> What I don't quite remember is why we had to implement it in QMP as a
>> no-op.  Might have been due to the way QMP and HMP were entangled back
>> then.
> Speaking of QMP and HMP 'entanglement', is the content of the wiki
> still valid?
>
> https://wiki.qemu.org/Features/QAPI

Looks quite stale to me.  I'm sorry this made you go down this rabbit
hole.

Paolo, we have numerous Features/ pages, and I suspect many of them are
too outdated to serve any purpose but confusing readers.  In theory,
"somebody" could go through them to identify stale ones.  In practice,
"somebody" doesn't exist, I'm afraid.  Should we summarily delete
Features/ pages that haven't seen an update in say more than a year?  Or
at least mark them as obsolete somehow?

> And under "HMP Conversion" we have:
>
> "For HMP commands that don't have QMP equivalents today, new QMP functions
> will be added to support these commands."

QMP need not provide the exact same commands.  It must provide
"equivalence".  Selecting a CPU is an instructive example.  HMP does it
with state: each HMP monitor has a current CPU, controlled with HMP
command cpu.  HMP commands implicitly use their monitor's current CPU.
In contrast, QMP eschews state, and makes the CPU explicit instead: you
specify the it as an argument.

> This in particular gave me the motivation to go ahead and implement qmp_cpu.
> But then again, the last entry on Status is "3/6/2011" so yeah, I
> should have
> asked here first whether the info from this wiki was relevant before sending
> the patch.

Touching base with the maintainer(s) first generally doesn't hurt.

[...]

  reply	other threads:[~2017-12-15 13:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-13 18:15 [Qemu-devel] [PATCH v1 0/2] QMP: implementing qmp_cpu Daniel Henrique Barboza
2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu Daniel Henrique Barboza
2017-12-14  2:18   ` Eric Blake
2017-12-14 15:21     ` Markus Armbruster
2017-12-14 19:46       ` Daniel Henrique Barboza
2017-12-15 13:56         ` Markus Armbruster [this message]
2017-12-15 18:11           ` Paolo Bonzini
2017-12-18  9:20             ` Markus Armbruster
2017-12-15 18:59         ` Dr. David Alan Gilbert
2017-12-18  9:12           ` Markus Armbruster
2017-12-13 18:15 ` [Qemu-devel] [PATCH v1 2/2] cpus.c: change qmp_query_cpus 'value->current' logic Daniel Henrique Barboza
2017-12-14 19:50   ` Daniel Henrique Barboza

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=87ind8nlh9.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=danielhb@linux.vnet.ibm.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=pbonzini@redhat.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.