From: Anthony Liguori <anthony@codemonkey.ws>
To: Avi Kivity <avi@redhat.com>
Cc: Juan Quintela <quintela@redhat.com>,
Jan Kiszka <jan.kiszka@siemens.com>,
qemu-devel@nongnu.org, Luiz Capitulino <lcapitulino@redhat.com>,
Anthony Liguori <aliguori@linux.vnet.ibm.com>,
Jan Kiszka <jan.kiszka@web.de>,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] Re: [PATCH v2 12/15] monitor: Add basic device state visualization
Date: Tue, 25 May 2010 08:31:10 -0500 [thread overview]
Message-ID: <4BFBD11E.7030609@codemonkey.ws> (raw)
In-Reply-To: <4BFBCE6A.1000201@redhat.com>
On 05/25/2010 08:19 AM, Avi Kivity wrote:
> On 05/25/2010 04:03 PM, Anthony Liguori wrote:
>>>
>>>> I don't think that qdev device names and paths are something we
>>>> have to worry much about changing over time since they reflect
>>>> logical bus layout. They should remain static provided the devices
>>>> remain static.
>>>
>>> Modulo mistakes. We already saw one (lack of pci domains). To
>>> reduce the possibility of mistakes, we need reviewable documentation.
>>
>>
>> pci domains was only a mistake as a nice-to-have. We can add pci
>> domains in a backwards compatible way.
>
> It adds a new level to the qdev tree.
The tree is not organized like that today. IOW, the PCI hierarchy is
not reflected in the qdev hierarchy. All PCI devices (regardless of
whether they're a function or a full slot) simply sit below the PCI bus.
>>
>> The arguments you're making about the importance of backwards
>> compatibility and what's needed to strongly guarantee it are equally
>> applicable to the live migration protocol. We really do need to
>> formally document the live migration protocol in such a way that it's
>> reviewable if we hope to truly make it compatible across versions.
>
> Mostly agreed. I think live migration has a faster/easier deprecation
> schedule (easier not to support migration from 0.n-k to 0.n than to
> remove qmp support for a feature introduced in 0.n-k when releasing
> 0.n). But that's a minor concern, improving our externally visible
> interface documentation is a good thing and badly needed.
>
Regards,
Anthony Liguori
next prev parent reply other threads:[~2010-05-25 13:48 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-22 8:17 [Qemu-devel] [PATCH v2 00/15] Basic device state visualization Jan Kiszka
2010-05-22 8:17 ` [Qemu-devel] [PATCH v2 01/15] Add dependency of JSON unit tests on config-host.h Jan Kiszka
2010-05-22 8:17 ` [Qemu-devel] [PATCH v2 02/15] qdev: Fix scanning across single-bus devices Jan Kiszka
2010-05-29 7:38 ` Markus Armbruster
2010-05-29 7:56 ` Jan Kiszka
2010-05-31 9:45 ` Gerd Hoffmann
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 03/15] qdev: Allow device addressing via 'driver.instance' Jan Kiszka
2010-05-29 7:50 ` Markus Armbruster
2010-05-29 8:09 ` Jan Kiszka
2010-05-31 8:43 ` Markus Armbruster
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 04/15] qdev: Convert device and bus lists to QTAILQ Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 05/15] qdev: Allow device specification by qtree path for device_del Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 06/15] qdev: Push QMP mode checks into qbus_list_bus/dev Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 07/15] monitor: Add completion for qdev paths Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 08/15] Add base64 encoder/decoder Jan Kiszka
2010-05-22 13:59 ` Blue Swirl
2010-05-23 7:55 ` Jan Kiszka
2010-05-23 8:48 ` Avi Kivity
2010-05-23 10:04 ` Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 09/15] QMP: Reserve namespace for complex object classes Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 10/15] Add QBuffer Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 11/15] monitor: return length of printed string via monitor_[v]printf Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 12/15] monitor: Add basic device state visualization Jan Kiszka
2010-05-22 18:55 ` [Qemu-devel] " Avi Kivity
2010-05-23 7:57 ` Jan Kiszka
2010-05-23 8:44 ` Avi Kivity
2010-05-23 10:03 ` Jan Kiszka
2010-05-23 10:42 ` Avi Kivity
2010-05-29 8:00 ` Markus Armbruster
2010-05-29 8:14 ` Jan Kiszka
2010-05-30 8:26 ` Avi Kivity
2010-05-30 12:36 ` Jan Kiszka
2010-05-31 8:46 ` Markus Armbruster
2010-05-31 8:58 ` Jan Kiszka
2010-05-31 11:07 ` Markus Armbruster
2010-05-31 11:11 ` Jan Kiszka
2010-05-24 12:51 ` Luiz Capitulino
2010-05-24 20:22 ` Anthony Liguori
2010-05-24 20:22 ` Anthony Liguori
2010-05-24 20:35 ` Jan Kiszka
2010-05-24 21:49 ` Anthony Liguori
2010-05-24 22:12 ` Jan Kiszka
2010-05-24 22:27 ` Anthony Liguori
2010-05-25 7:23 ` Avi Kivity
2010-05-25 13:03 ` Anthony Liguori
2010-05-25 13:19 ` Avi Kivity
2010-05-25 13:31 ` Anthony Liguori [this message]
2010-05-25 13:41 ` Avi Kivity
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 13/15] QMP: Teach basic capability negotiation to python example Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 14/15] QMP: Fix python helper /wrt long return strings Jan Kiszka
2010-05-22 8:18 ` [Qemu-devel] [PATCH v2 15/15] QMP: Add support for buffer class to qmp python helper Jan Kiszka
2010-05-22 14:05 ` [Qemu-devel] [PATCH v2 00/15] Basic device state visualization Blue Swirl
2010-05-23 7:55 ` Jan Kiszka
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=4BFBD11E.7030609@codemonkey.ws \
--to=anthony@codemonkey.ws \
--cc=aliguori@linux.vnet.ibm.com \
--cc=armbru@redhat.com \
--cc=avi@redhat.com \
--cc=jan.kiszka@siemens.com \
--cc=jan.kiszka@web.de \
--cc=lcapitulino@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
/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).