qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH v1 1/2] qmp.c: (re)implement qmp_cpu
Date: Fri, 15 Dec 2017 14:56:18 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Daniel Henrique Barboza <address@hidden> writes:

> On 12/14/2017 01:21 PM, Markus Armbruster wrote:
>> Eric Blake <address@hidden> 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 via email to

[Prev in Thread] Current Thread [Next in Thread]