qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com>
To: Luiz Capitulino <lcapitulino@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-s390x@nongnu.org,
	ehabkost@redhat.com, pbonzini@redhat.com,
	crosthwaite.peter@gmail.com, dgilbert@redhat.com,
	rth@twiddle.net, cohuck@redhat.com, borntraeger@de.ibm.com,
	agraf@suse.de, david@redhat.com, eblake@redhat.com,
	armbru@redhat.com, berrange@redhat.com
Subject: Re: [Qemu-devel] [PATCH 3/3] qmp: add architecture specific cpu data for query-cpus-fast
Date: Tue, 13 Feb 2018 13:30:02 +0100	[thread overview]
Message-ID: <9757bd46-06f2-1ce2-9cbd-9118c4a6cb9c@linux.vnet.ibm.com> (raw)
In-Reply-To: <20180212131504.1243e696@redhat.com>

On 12.02.2018 19:15, Luiz Capitulino wrote:
> On Mon, 12 Feb 2018 13:14:32 +0100
> Viktor Mihajlovski <mihajlov@linux.vnet.ibm.com> wrote:
> 
>> -{ 'struct': 'CpuInfoFast',
>> -  'data': {'cpu-index': 'int', 'qom-path': 'str',
>> -           'thread-id': 'int', '*props': 'CpuInstanceProperties' } }
>> +{ 'union': 'CpuInfoFast',
>> +  'base': {'cpu-index': 'int', 'qom-path': 'str',
>> +           'thread-id': 'int', '*props': 'CpuInstanceProperties',
>> +           'arch': 'CpuInfoArch' },
>> +  'discriminator': 'arch',
>> +  'data': { 'x86': 'CpuInfoOther',
>> +            'sparc': 'CpuInfoOther',
>> +            'ppc': 'CpuInfoOther',
>> +            'mips': 'CpuInfoOther',
>> +            'tricore': 'CpuInfoOther',
>> +            's390': 'CpuInfoS390Fast',
>> +            'other': 'CpuInfoOther' } }
> 
> Consider this a minor comment (and QMP maintainers can give a much
> better advice than me), but I think this arch list has problems. For
> one thing, it's incomplete. And the second problem is the 'other'
> field. What happens when QEMU starts supporting a new arch? 'other'
> becomes the new arch. Is this compatible? I don't know.
This seems to be the customary approach, see
https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg01986.html
> 
> I don't know if this would work with the QAPI, but you could have
> a '*arch-data' field in the CpuInfoFast definition, like:
> 
> 'data': { ..., '*arch-data': 'CpuInfoFastArchData' }
> 
> where 'CpuInfoFastArchData' is defined by each arch that supports
> the field. An arch supporting the field could also export a
> query_cpus_fast_arch() function, which is called by qmp_query_cpus_fast().
> 
I had it like this in my first reply to your initial patch. However,
that adds an additional hierarchy level in the return data. This
prevents clients like libvirt to reuse the data extraction code when
they switch over to using query-cpus-fast.

-- 
Regards,
 Viktor Mihajlovski

  reply	other threads:[~2018-02-13 12:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-12 12:14 [Qemu-devel] [PATCH 0/3] add query-cpu-fast and related s390 changes Viktor Mihajlovski
2018-02-12 12:14 ` [Qemu-devel] [PATCH 1/3] qmp: expose s390-specific CPU info Viktor Mihajlovski
2018-02-12 15:52   ` Cornelia Huck
2018-02-12 16:20     ` Viktor Mihajlovski
2018-02-12 18:03   ` Luiz Capitulino
2018-02-13 11:16     ` [Qemu-devel] [qemu-s390x] " David Hildenbrand
2018-02-13 12:20       ` Viktor Mihajlovski
2018-02-13 15:10         ` Eric Blake
2018-02-12 20:30   ` [Qemu-devel] " David Hildenbrand
2018-02-12 12:14 ` [Qemu-devel] [PATCH 2/3] qmp: add query-cpus-fast Viktor Mihajlovski
2018-02-12 16:06   ` Cornelia Huck
2018-02-12 16:50   ` Dr. David Alan Gilbert
2018-02-13 15:14     ` Viktor Mihajlovski
2018-02-12 20:35   ` David Hildenbrand
2018-02-12 12:14 ` [Qemu-devel] [PATCH 3/3] qmp: add architecture specific cpu data for query-cpus-fast Viktor Mihajlovski
2018-02-12 16:23   ` Cornelia Huck
2018-02-13 16:12     ` Viktor Mihajlovski
2018-02-13 16:17       ` Cornelia Huck
2018-02-12 18:15   ` Luiz Capitulino
2018-02-13 12:30     ` Viktor Mihajlovski [this message]
2018-02-13 13:41       ` Luiz Capitulino
2018-02-12 15:38 ` [Qemu-devel] [PATCH 0/3] add query-cpu-fast and related s390 changes Cornelia Huck
2018-02-12 16:26   ` Viktor Mihajlovski

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=9757bd46-06f2-1ce2-9cbd-9118c4a6cb9c@linux.vnet.ibm.com \
    --to=mihajlov@linux.vnet.ibm.com \
    --cc=agraf@suse.de \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=borntraeger@de.ibm.com \
    --cc=cohuck@redhat.com \
    --cc=crosthwaite.peter@gmail.com \
    --cc=david@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=eblake@redhat.com \
    --cc=ehabkost@redhat.com \
    --cc=lcapitulino@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-s390x@nongnu.org \
    --cc=rth@twiddle.net \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).