qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 5/6] qapi: extract CpuInfoCommon to mitigate sch


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 5/6] qapi: extract CpuInfoCommon to mitigate schema duplication
Date: Thu, 26 Apr 2018 08:19:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)

Laszlo Ersek <address@hidden> writes:

> On 04/25/18 21:12, Eric Blake wrote:
>> On 04/25/2018 08:20 AM, Laszlo Ersek wrote:
>> 
>>> ...
>>>
>>> and people would ask themselves ever after, "are there some common
>>> fields in there that we could extract ... hmmm, @props and @arch, okay,
>>> maybe, maybe not, grey area". Let's do it now and save them the thinking.
>> 
>> No, CpuInfo is slated for death in the next year or so; per commit
>> ff9a9156.

Good catch, I missed it.

>>            Once it disappears (in 2.14 or 2.15?), we will ONLY have
>> CpuInfoFast (although we might rename it at that time, as the name of
>> QMP structs is not part of the introspection interface).
>> 
>> So, my personal inclination is to just live with the mindless
>> near-duplication until the deprecation period ends, rather than wasting
>> cycles refactoring things just to refactor it back out when removing the
>> dead code later.
>> 
>
> This is an important update; thank you for it. Because, it tells me that
> we might not need to add @target to CpuInfo at all. Why *extend* an
> interface that is deprecated to the point that we're reluctant even to
> *refactor* it?
>
> (BTW, I had noticed the deprecation note in the schema source code, from
> what you've now identified as commit ff9a9156; I didn't know what it
> meant -- I didn't know it carried a removal sentence.)

No need to enhance it even without a removal sentence.

> The consequence is that I could drop the painful modifications for
> qmp_query_cpus() altogether, and just keep the simple ones for
> qmp_query_cpus_fast().
>
> Markus, does that work for you? Forget about @CpuInfo for good?

Absolutely.



reply via email to

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