All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Eric Blake <eblake@redhat.com>
Cc: Daniel Henrique Barboza <danielhb@linux.vnet.ibm.com>,
	qemu-devel@nongnu.org, dgilbert@redhat.com
Subject: Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu
Date: Thu, 14 Dec 2017 16:21:57 +0100	[thread overview]
Message-ID: <87ind9xrl6.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <de0c5647-ca81-f5be-db52-9f0d3b173dac@redhat.com> (Eric Blake's message of "Wed, 13 Dec 2017 20:18:43 -0600")

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.

>>                                                      This patch brings
>> the logic of hmp_cpu to qmp_cpu and converts the HMP function to use its
>> QMP counterpart.
>
> I'm not sure I like this. HMP is stateful (you have to remember what
> previous 'cpu' commands have been run to tell what the current command
> will do).  That may be convenient (if not confusing) to humans, but is
> lousy for machine interfaces.  QMP should be stateless as much as
> possible - for any command that would behave differently according to
> what CPU is selected, THAT command (and not a different 'cpu' command
> executed previously) should have a cpu argument alongside all its other
> parameters.
>
> So unless you have a really strong use case for this, I don't think we
> want it.
>
>
>> +++ b/qapi-schema.json
>> @@ -1048,11 +1048,19 @@
>>  ##
>>  # @cpu:
>>  #
>> -# This command is a nop that is only provided for the purposes of compatibility.
>> +# Set the default CPU.
>>  #
>> -# Since: 0.14.0
>> +# @index: The index of the virtual CPU to be set as default
>> +#
>> +# Returns: Nothing on success
>> +#
>> +# Since: 2.12.0
>> +#
>> +# Example:
>> +#
>> +# -> { "execute": "cpu", "arguments": { "index": 2 } }
>> +# <- { "return": {} }
>>  #
>> -# Notes: Do not use this command.
>>  ##
>>  { 'command': 'cpu', 'data': {'index': 'int'} }
>>  
>> diff --git a/qmp.c b/qmp.c
>> index e8c303116a..c482225d5c 100644
>> --- a/qmp.c
>> +++ b/qmp.c
>> @@ -115,7 +115,9 @@ void qmp_system_powerdown(Error **erp)
>>  
>>  void qmp_cpu(int64_t index, Error **errp)
>>  {
>> -    /* Just do nothing */
>> +    if (monitor_set_cpu(index) < 0) {
>> +        error_setg(errp, "Invalid CPU index");
>> +    }
>>  }
>>  
>>  void qmp_cpu_add(int64_t id, Error **errp)
>> 
>
> Better yet, let's document that 'cpu' is deprecated, so that we can
> remove it from QMP altogether in a couple of releases.

Yes.

The standard way to deprecate a feature is to add it to appendix
"Deprecated features" in qemu-doc.texi, and make its use trigger
suitable deprecation messages, pointing to a replacement if any.

Unfortunately, we still lack means to signal "X is deprecated, use Y
instead" to a QMP client.  Not important in this case, because the
command has never worked.

  reply	other threads:[~2017-12-14 15:22 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 [this message]
2017-12-14 19:46       ` Daniel Henrique Barboza
2017-12-15 13:56         ` Markus Armbruster
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=87ind9xrl6.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=danielhb@linux.vnet.ibm.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@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.