From: Paolo Bonzini <pbonzini@redhat.com>
To: Eduardo Habkost <ehabkost@redhat.com>,
Igor Mammedov <imammedo@redhat.com>
Cc: libvir-list@redhat.com, "Jiri Denemark" <jdenemar@redhat.com>,
"Peter Krempa" <pkrempa@redhat.com>,
qemu-devel@nongnu.org, "Andreas Färber" <afaerber@suse.de>
Subject: Re: [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing
Date: Fri, 02 May 2014 16:54:00 +0200 [thread overview]
Message-ID: <5363B188.9090500@redhat.com> (raw)
In-Reply-To: <20140502144305.GJ3363@otherpad.lan.raisama.net>
Il 02/05/2014 16:43, Eduardo Habkost ha scritto:
> The first thing I considered was making icc-bus user-creatable. Then I
> noticed it wouldn't work because object-add always add objects to
> /objects, not inside the qdev hierarchy (that's where device_add looks
> for the bus).
>
> So, allowing device_add could be possible, but would require changing
> more basic infrastructure: either allowing bus-less devices on
> device_add, or allowing device_add to add devices outside the qdev
> hierarchy, or allowing object-add to create objects outside /objects.
>
> Simply making CPU objects work with object-add was much simpler and less
> intrusive. And it had the interesting side-effect of _not_ doing things
> that are not required for CPU model probing (like creating an actual
> VCPU thread).
I like this series in general. I have only some doubts about making the
code somewhat future-proof, hence the three questions I have are really
variations of this same doubt:
* is it worthwhile to extend this to other devices, for management to
query default values of the properties?
* how does this interact with future QOMification of device hotplug
where devices will be hotplugged with object-add? Should
Device::UserCreatable::complete set realized to true in this case in the
future? How will Device::UserCreatable::complete distinguish the two cases?
* Related to this, if Device::UserCreatable::complete will set realized
to true, how will we handle hotplug of interconnected devices where
device 1 needs a link to device 2 and device 2 needs a link to device 1?
Paolo
next prev parent reply other threads:[~2014-05-02 14:54 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1398889773-14652-1-git-send-email-ehabkost@redhat.com>
2014-05-02 13:45 ` [Qemu-devel] [RFC 0/5] Allow object-add on X86CPU subclasses, for CPU model probing Igor Mammedov
2014-05-02 14:43 ` Eduardo Habkost
2014-05-02 14:54 ` Paolo Bonzini [this message]
2014-05-02 16:43 ` Eduardo Habkost
2014-05-06 7:22 ` Igor Mammedov
2014-05-06 14:42 ` Eduardo Habkost
2014-05-06 20:01 ` Igor Mammedov
2014-05-06 20:19 ` Eduardo Habkost
2014-05-06 20:29 ` Andreas Färber
2014-05-08 18:29 ` Eduardo Habkost
2014-05-15 12:35 ` Igor Mammedov
2014-05-15 13:07 ` Eduardo Habkost
2014-05-15 13:09 ` Andreas Färber
2014-05-15 13:48 ` Igor Mammedov
2014-05-15 14:03 ` Eduardo Habkost
2014-05-16 14:52 ` Igor Mammedov
2014-05-16 15:16 ` Eduardo Habkost
2014-05-16 14:57 ` Andreas Färber
2014-05-06 22:13 ` [Qemu-devel] [libvirt] " Eric Blake
2014-05-15 12:14 ` [Qemu-devel] " Igor Mammedov
2014-05-15 13:35 ` Eduardo Habkost
[not found] ` <1398889773-14652-2-git-send-email-ehabkost@redhat.com>
2014-05-15 12:28 ` [Qemu-devel] [RFC 1/5] cpu: Initialize cpu->stopped=true earlier Igor Mammedov
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=5363B188.9090500@redhat.com \
--to=pbonzini@redhat.com \
--cc=afaerber@suse.de \
--cc=ehabkost@redhat.com \
--cc=imammedo@redhat.com \
--cc=jdenemar@redhat.com \
--cc=libvir-list@redhat.com \
--cc=pkrempa@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.